Phishing-as-a-Service no Microsoft 365: Detectar e Bloquear Kits PhaaS em 2026

PhaaS · Phishing · Microsoft 365 · ARToken · EvilTokens · Exchange Online · Anti-Spam · Mailflow  |  ✎ Duarte Spínola  |  2026-07-07

O Phishing-as-a-Service (PhaaS) transformou o panorama de ameaças para PME portuguesas. Kits como o ARToken (exposto em Julho 2026 pela BleepingComputer) permitem que atacantes sem conhecimentos técnicos lancem campanhas de phishing sofisticadas contra inquilinos Microsoft 365, com evasão de MFA e roubo de tokens. Este guia prático mostra como detectar, bloquear e responder a ataques PhaaS, com base na documentação Microsoft Security e no CISA. Para uma visão geral de phishing moderno, consulta o artigo Phishing Moderno: Detectar e Prevenir.

Conteúdos

• 1. O Que é Phishing-as-a-Service (PhaaS)
• 2. ARToken e EvilTokens: Como Funcionam
• 3. Técnicas de Evasão MFA
• 4. Sinais de Compromisso (IOC)
• 5. Hardening de Autenticação no M365
• 6. Regras de Transporte Exchange Online
• 7. Anti-Phishing Policies no Defender
• 8. Conditional Access para Logins Suspeitos
• 9. Monitorização com Sentinel e KQL
• 10. Resposta a Incidente
• 11. Formação de Utilizadores
• 12. PhaaS vs Phishing Tradicional
• 13. Cenário Prático PME
• 14. Checklist de Proteção

1. O Que é Phishing-as-a-Service (PhaaS)

PhaaS é um modelo de cibercrime onde atacantes alugam infraestrutura de phishing completa — páginas falsas, domínios, evasão de MFA, roubo de credenciais e painel de gestão — por subscrição mensal (tipicamente $50-$500/mês). O cliente (atacante) não precisa de conhecimentos técnicos; fornece apenas a lista de alvos. Kits PhaaS como ARToken, EvilProxy e Modlishka tornaram o phishing numa indústria commoditizada.

2. ARToken e EvilTokens: Como Funcionam

O ARToken funciona como um reverse proxy adversary-in-the-middle (AiTM): a vítima liga-se ao servidor do atacante (que parece o login.microsoft.com), o servidor reencaminha o tráfego para Microsoft, e em tempo real captura as credenciais, o token MFA e os cookies de sessão. Quando a vítima completa o MFA, o atacante recebe o session token válido e usa-o para aceder à conta sem precisar de repetir o MFA.

# Fluxo de ataque ARToken:
# 1. Vítima recebe email com link para "login-microsoft365-verify.com"
# 2. Vítima introduz credenciais na página falsa (proxy reverso)
# 3. ARToken reencaminha credenciais para login.microsoftonline.com
# 4. Microsoft pede MFA → ARToken reencaminha para vítima
# 5. Vítima aprova MFA (TOTP/SMS/push)
# 6. Microsoft emite session token → ARToken captura token
# 7. Atacante usa token para aceder a M365 sem MFA
# 8. Token válido por ~1h (ou mais se não houver CAE)

# Verificar tokens ativos no Entra ID
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Top 10 |
    Select-Object UserDisplayName, ClientAppUsed,
           ConditionalAccessStatus, IpAddress, Location

3. Técnicas de Evasão MFA Usadas por Kits PhaaS

Os kits PhaaS modernos usam várias técnicas para contornar MFA. Para uma análise mais ampla de técnicas de phishing, consulta o artigo Phishing Moderno.

# Técnicas de evasão MFA usadas por PhaaS:
# 1. AiTM (Adversary-in-the-Middle) — proxy reverso captura token
# 2. Token theft — roubo de cookie de sessão após MFA
# 3. Push bombing — envio de múltiplas notificações MFA push
# 4. MFA fatigue — repetição até utilizador aprovar por cansaço
# 5. SIM swapping — desvio de SMS MFA
# 6. Device code phishing — uso de fluxo device code para obter token

# Verificar se há logins via device code suspeitos
Get-MgAuditLogSignIn -Filter "clientAppUsed eq 'Device Code'" |
    Select-Object UserDisplayName, IpAddress, CreatedDateTime |
    Sort-Object CreatedDateTime -Descending

4. Sinais de Compromisso (IOC) — Como Detectar

Indicadores de compromisso (IOCs) que sugerem ataque PhaaS bem-sucedido:

# 1. Logins de IPs não habituais ou países inesperados
Get-MgAuditLogSignIn -Top 50 |
    Where-Object { $_.Location -notmatch "Portugal" } |
    Select-Object UserDisplayName, IpAddress, Location, CreatedDateTime

# 2. Logins bem-sucedidos seguidos de atividade suspeita
# (criação de regras de inbox, forwarding, novas delegates)
Get-MgUserMessage -UserId $userId -Top 10 |
    Where-Object { $_.ForwardingSettings -ne $null }

# 3. Novas regras de transporte Exchange criadas
Connect-ExchangeOnline
Get-InboxRule -Mailbox $userEmail |
    Where-Object { $_.ForwardTo -ne $null -or $_.RedirectTo -ne $null }

# 4. Tokens de sessão criados fora do horário normal
Get-MgAuditLogSignIn |
    Where-Object { $_.CreatedDateTime.Hour -lt 7 -or $_.CreatedDateTime.Hour -gt 20 } |
    Select-Object UserDisplayName, CreatedDateTime, IpAddress

5. Hardening de Autenticação no Microsoft 365

Para proteger contra token theft, é obrigatório ativar Continuous Access Evaluation (CAE) e resistance to token theft no Entra ID. Para mais contexto sobre MFA, consulta o artigo sobre Microsoft Entra MFA.

# ativar CAE (Continuous Access Evaluation) no Entra ID
# Portal > Entra ID > Security > Conditional Access
# Criar policy que requer "Require token theft resistance"

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$caePolicy = @{
    DisplayName = "CA-Token-Theft-Resistance"
    State = "enabled"
    Conditions = @{
        Applications = @{ IncludeApplications = @("All") }
        Users = @{ IncludeUsers = @("All") }
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("mfa")
        AuthenticationStrength = @{
            Id = "00000000-0000-0000-0000-000000000004"  # Phishing-resistant MFA
        }
    }
    SessionControls = @{
        ContinuousAccessEvaluation = @{
            Mode = "strict"
        }
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $caePolicy

6. Regras de Transporte Exchange Online (Mailflow)

As regras de transporte (mailflow rules) são a primeira linha de defesa — podem bloquear emails com características típicas de PhaaS antes de chegarem à caixa de entrada. Documentação oficial: Mail flow rules in Exchange Online.

# Bloquear emails com URLs suspeitas (domínios recentemente registados)
New-TransportRule -Name "Block-Recently-Registered-Domains" `
    -SenderDomainLocation "OutsideOrganization" `
    -ExceptIfSenderDomainIs @("empresa.pt", "parceiro.pt") `
    -SetSCL 9 `
    -Comments "Bloqueia emails com links para domínios registados há menos de 30 dias"

# Adicionar warning banner a emails externos
New-TransportRule -Name "External-Email-Warning" `
    -FromScope "NotInOrganization" `
    -PrependSubject "[EXTERNO] " `
    -ApplyDisclaimer @{
        Text = "⚠️ ATENÇÃO: Este email foi enviado de fora da organização. Não clique em links nem abra anexos se não confirma o remetente."
        Location = "Prepend"
        FallbackAction = "Wrap"
    }

# Bloquear anexos com macros
New-TransportRule -Name "Block-Macro-Attachments" `
    -AttachmentHasExecutableContent $true `
    -SetSCL 9

7. Configurar Anti-Phishing Policies no Defender for Office 365

As anti-phishing policies no Defender for Office 365 incluem proteção contra spoofing, impersonation e domínios similares. Para implementação do Defender, consulta Microsoft Defender para Endpoint.

# Criar Anti-Phishing Policy
Set-AntiPhishPolicy -Identity "PhishDef-Strict" `
    -EnableTargetedUserProtection $true `
    -EnableOrganizationDomainsProtection $true `
    -EnableSimilarDomainsSafetyTips $true `
    -EnableSimilarUsersSafetyTips $true `
    -EnableUnusualCharactersSafetyTips $true `
    -EnableMailboxIntelligence $true `
    -EnableMailboxIntelligenceProtection $true `
    -MailboxIntelligenceProtectionAction MoveToJmf `
    -TargetedUserProtectionAction Quarantine `
    -SpoofQuarantineAction Quarantine `
    -PhishThresholdLevel 2

8. Conditional Access para Bloquear Logins Suspeitos

# Bloquear logins de países não autorizados
$geoPolicy = @{
    DisplayName = "CA-Block-NonPT-Countries"
    State = "enabled"
    Conditions = @{
        Applications = @{ IncludeApplications = @("All") }
        Users = @{ IncludeUsers = @("All") }
        Locations = @{
            IncludeLocations = @("All")
            ExcludeLocations = @("PT-Portugal")
        }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("block")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $geoPolicy

# Exigir dispositivo gerido (Intune compliant) para acesso M365
$devicePolicy = @{
    DisplayName = "CA-Require-Compliant-Device"
    State = "enabled"
    Conditions = @{
        Applications = @{ IncludeApplications = @("Office365") }
        Users = @{ IncludeUsers = @("All") }
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("compliantDevice", "mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $devicePolicy

9. Monitorização com Microsoft Sentinel e KQL

Para PME com Sentinel, as seguintes queries KQL detectam atividade de PhaaS. Para implementação do Sentinel, consulta Microsoft Sentinel para PME.

// Detectar logins bem-sucedidos seguidos de criação de regras de forwarding
let suspiciousLogins = SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where Location != "Portugal"
| project TimeGenerated, UserPrincipalName, IpAddress, Location;
let ruleCreations = OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation == "New-InboxRule"
| where Parameters has "ForwardTo" or Parameters has "RedirectTo"
| project TimeGenerated, UserId, Operation;
suspiciousLogins
| join kind=inner (ruleCreations) on $left.UserPrincipalName == $right.UserId
| extend TimeDiff = TimeGenerated1 - TimeGenerated
| where TimeDiff between (0min .. 60min)
| project UserPrincipalName, IpAddress, Location, TimeGenerated, Operation, TimeDiff

// Detectar múltiplos logins de IPs diferentes em curto espaço de tempo
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
| summarize DistinctIPs = dcount(IpAddress), IPs = make_set(IpAddress)
    by UserPrincipalName
| where DistinctIPs > 3
| project UserPrincipalName, DistinctIPs, IPs
| order by DistinctIPs desc

10. Resposta a Incidente: Passos Imediatos

# RESPOSTA A INCIDENTE PHaaS — Passos imediatos

# 1. Revogar todas as sessões do utilizador comprometido
Revoke-MgUserSignInSession -UserId $compromisedUserId

# 2. Reset password
Update-MgUser -UserId $compromisedUserId `
    -PasswordProfile @{
        Password = (New-PasswordComplex)
        ForceChangePasswordNextSignIn = $true
    }

# 3. Remover regras de forwarding maliciosas
Get-InboxRule -Mailbox $compromisedEmail | Remove-InboxRule

# 4. Bloquear login temporariamente
Update-MgUser -UserId $compromisedUserId -AccountEnabled $false

# 5. Verificar logs de acesso (últimas 24h)
Get-MgAuditLogSignIn -Filter "userId eq '$compromisedUserId'" |
    Select-Object CreatedDateTime, IpAddress, Location, ClientAppUsed

# 6. Notificar equipa de segurança e registar ticket
# Ver artigo: Registar e Documentar Tickets de Sysadmin

11. Formação de Utilizadores: A Última Linha de Defesa

Nenhuma tecnologia substitui formação adequada. A CISA Secure Our World recomenda simulações de phishing trimestrais. PME devem usar o Attack Simulator no Defender for Office 365 para enviar emails de phishing simulados e medir a taxa de clique.

# Lançar simulação de phishing via Defender for Office 365
# Portal > Microsoft 365 Defender > Email & collaboration > Attack simulator

# Ver resultados de simulações anteriores
Get-AttackSimulationSimulation |
    Select-Object DisplayName, SimulationType, Status,
           @{N="ClickRate";E={[math]::Round($_.Metrics.ClickRate * 100, 1)}} |
    Sort-Object CreatedDateTime -Descending

# Ver utilizadores que falharam múltiplas simulações
Get-AttackSimulationSimulationUser |
    Where-Object { $_.SimulationEvents.ClickedLink -eq $true } |
    Group-Object EmailAddress |
    Where-Object Count -gt 2 |
    Select-Object Name, Count

12. Comparação: PhaaS vs Phishing Tradicional

13. Cenário Prático PME (ataque real simulado)

# Cenário: PME 50 cols, M365 E3 + Defender for Office P1
# Ataque: Email PhaaS ARToken disfarçado de "Microsoft 365 Password Expiry"

# 1. Email recebido:
# From: [email protected] (spoofed)
# Subject: "A tua palavra-passe expira em 24 horas — Renova já"
# Link: https://login-microsoft365-verify.com/auth (proxy ARToken)

# 2. Vítima clica, introduz credenciais, aprova MFA push
# 3. Atacante recebe token de sessão
# 4. Atacante cria regra de forwarding para email externo
# 5. Defender detecta: anomalia de login (IP Brasil)

# Resposta automática via Sentinel:
SecurityAlert
| where TimeGenerated > ago(10min)
| where SystemAlertId has "PhaaS" or SystemAlertId has "AnomalousSignIn"
| project AlertName, Severity, Entities

14. Checklist de Proteção

Artigos Relacionados

• Phishing Moderno: Detectar e Prevenir
• Microsoft Sentinel: SIEM para PME
• Microsoft Entra MFA
• Zero Trust para PME
• Microsoft Defender para Endpoint
• PIM: Gestão de Acesso Privilegiado

← Voltar ao Índice