Phishing Moderno: Como Detectar e Prevenir Ataques além do Login em 2026

Phishing · MFA Fatigue · Evilginx · Anti-phishing · Defender · DMARC

Por Duarte Spínola · 2 julho 2026 · kbase.pt

O phishing em 2026 já não é o email mal escrito com erros ortográficos e links óbvios para domínios duvidosos. Os ataques modernos usam inteligência artificial para gerar mensagens perfeitas, kits prontos a usar como o Evilginx2 para interceptar sessões MFA, campanhas de MFA fatigue que bombardeiam o telemóvel da vítima às 3 da manhã, e mensagens SMS que chegam como se fossem da DGT ou da Segurança Social. O login deixou de ser o único alvo — hoje os atacantes querem a sessão, o token, o cookie, e o consentimento OAuth. Este guia percorre o cenário completo, desde os tipos de ataque modernos até à configuração de DMARC, Defender para Office 365, Conditional Access e resposta a incidentes, com comandos PowerShell prontos a executar.

Tema

Phishing moderno, detecção e prevenção

Versão / data

Julho 2026

Audiência

Administradores IT, gestores de segurança, decisores PME

Pré-requisitos

Inquilino Microsoft 365, licença Defender para Office 365 Plan 1 ou 2, acesso Entra ID P1/P2

Legislação

Diretiva NIS2 (UE) 2022/2555, RGPD (UE) 2016/679

Neste artigo

• 1. O Cenário do Phishing em 2026
• 2. Tipos de Phishing Moderno
• 3. Ataques MFA Fatigue (MFA Bombing)
• 4. Phishing Kits e Evilginx2
• 5. Como os Ataques Bypassam MFA
• 6. Defender para Office 365
• 7. Configurar DMARC/SPF/DKIM
• 8. Conditional Access para Prevenir Phishing
• 9. Treinar Utilizadores
• 10. Detectar Phishing com Logs
• 11. Responder a um Incidente de Phishing
• 12. Ferramentas Open-Source Anti-Phishing
• 13. Boas Práticas para PMEs
• 14. Checklist Anti-Phishing

---

1. O Cenário do Phishing em 2026

O phishing é, desde há mais de uma década, o vetor de entrada mais comum em incidentes de segurança. Segundo o CISA, mais de 90% dos ciberataques começam com email de phishing. O que mudou em 2026 é a sofisticação: os atacantes usam modelos de linguagem para gerar emails perfeitos em português europeu, imitam domínios com precisão caracter-por-caracter, e operam infraestruturas que rodam reverse proxies capazes de interceptar sessões autenticadas.

Em Portugal, o cenário agrava-se com a adoção massiva do Microsoft 365 nas PME e a entrada em vigor da NIS2. As PME portuguesas tornaram-se alvos atrativos: têm inquilinos Entra ID com dados sensíveis, usam Defender para Office 365 frequentemente mal configurado, e raramente implementam DMARC em modo de rejeição. O atacante sabe que basta uma sessão roubada para aceder ao Teams, SharePoint, OneDrive e email — sem precisar de voltar a autenticar.

Os três vetores que definem o phishing moderno em 2026:

• IA generativa: emails personalizados, sem erros ortográficos, com contexto específico obtido de LinkedIn, site da empresa e redes sociais. O custo de gerar 10 000 emails personalizados caiu para centimos.
• Reverse proxy phishing (AitM): o atacante faz de man-in-the-middle, interceta credenciais e o token de sessão MFA. O MFA deixa de proteger — a sessão é roubada após autenticação bem-sucedida.
• Consent phishing (OAuth illegitimate): o atacante pede consentimento a uma app maliciosa que acede ao Microsoft Graph. Não rouba a password — rouba um access token que persiste durante dias ou meses.

2. Tipos de Phishing Moderno (spear, whale, smishing, vishing)

O phishing moderno diversificou-se em variantes especializadas, cada uma com vetor, público-alvo e técnica próprios. Conhecer as categorias é o primeiro passo para detectar padrões e calibrar defesas.

Tipo	Canal	Alvo	Característica 2026
Spear phishing	Email	Indivíduo ou equipa específica	Personalizado com IA a partir de dados públicos (LinkedIn, site institucional)
Whaling	Email	CEO, CFO, diretores	Falsificação de identidade executiva para autorizar transferências ou acesso a dados
Smishing	SMS / MMS	Consumidores e colaboradores	Falsificação de DGT, Segurança Social, CTT, bancos; links curtos que escapam a filtros de email
Vishing	Voz (telefone)	Público geral, apoio ao cliente	Voz sintética (deepfake) a imitar gestores ou apoio técnico
Quishing	QR code	Colaboradores, visitantes	QR code em cartaz/fisicamente leva a página de login maliciosa; bypassa filtros de email
Consent phishing	OAuth/Graph	Utilizadores Microsoft 365/Google	App maliciosa pede consentimento; token de acesso persiste sem password

Em Portugal, o smishing teve um surto particularmente virulento em 2025-2026 com mensagens que imitam a CNPD, a Autoridade Tributária e a Segurança Social. A maioria pede “regularização” de dados, pagamento de multas ou verificação de conta, com um link curto que redireciona para uma página de roubo de credenciais bancárias.

3. Ataques MFA Fatigue (MFA Bombing)

O ataque de MFA fatigue, também conhecido como MFA bombing, é brutalmente simples: o atacante já tem a password da vítima (obtida por leak, credential stuffing ou compra no dark web) e dispara dezenas ou centenas de pedidos de push notification via Microsoft Authenticator. Às 3 da manhã, depois de 40 notificações, a vítima cansada aprova uma só para que o telemóvel pare de vibrar. O atacante está dentro.

Este vetor foi imortalizado em 2022 pelo ataque à Uber, onde um atacante usou MFA fatigue contra um colaborador até obter aprovação. Continua a ser, em 2026, uma das técnicas mais usadas contra contas Microsoft 365 — porque funciona contra qualquer inquilino que use push notifications sem number matching.

As defesas contra MFA fatigue são:

• Number matching: o utilizador tem de introduzir um número mostrado no ecrã de login. O atacante não consegue ver esse número — só a vítima. Aprovar sem o número correto é impossível.
• Additional context: o pedido mostra a localização geográfica, aplicação e IP de origem. Um pedido do Brasil às 3h para um utilizador em Lisboa é imediatamente suspeito.
• Conditional Access com location conditions: bloquear pedidos de MFA fora de países/regiões autorizadas.
• Authentication Methods Policy: ativar number matching e additional context via Graph PowerShell ou portal Entra ID.
• FIDO2 para contas privilegiadas: chaves de segurança físicas eliminam completamente o vetor MFA fatigue.

Para ativar number matching e additional context no inquilino Entra ID via PowerShell:

# Conectar ao Microsoft Graph com permissões necessárias
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

# Obter a política de métodos de autenticação atual
Get-MgPolicyAuthenticationMethodPolicy

# Ativar number matching e additional context no Microsoft Authenticator
$params = @{
    "@odata.type" = "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration"
    state = "enabled"
    features = @{
        featureSettings = @{
            numberMatching = @{
                state = "enabled"
            }
            additionalContext = @{
                state = "enabled"
            }
        }
    }
}

Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "MicrosoftAuthenticator" `
    -BodyParameter $params

4. Phishing Kits e Evilginx2 (reverse proxy phishing)

O Evilginx2 é um framework open-source que funciona como reverse proxy. A vítima acede a um domínio que imita o site legítimo (ex: microsoftonline-login.com); o Evilginx2 reencaminha o tráfego para o site real da Microsoft, mostra a página de login verdadeira (com o conteúdo dinâmico correto), e quando a vítima faz MFA com a app Authenticator, o token de sessão é intercetado pelo proxy. O atacante fica com o cookie de sessão válido — não precisa da password, não precisa de re-autenticar. O MFA foi completado com sucesso; a sessão foi simplesmente roubada após.

Este ataque é designado AitM (Adversary-in-the-Middle) e é, em 2026, o padrão de phishing mais eficaz contra contas Microsoft 365. Kits baseados em Evilginx2 circulam em fóruns criminosos com templates para Microsoft, Google, PayPal, bancos portugueses e redes sociais. O custo de um kit pronto a usar ronda os 200 a 500 euros, com suporte e atualizações.

O fluxo de um ataque Evilginx2:

1. O atacante regista um domínio look-alike (ex: micros0ft-login.com) e configura certificados TLS via Let’s Encrypt.
2. O Evilginx2 atua como reverse proxy com um phishlet para Microsoft 365.
3. A vítima clica num link no email e é redirecionada para o domínio malicioso, que parece legítimo (TLS, layout idêntico).
4. A vítima introduz credenciais e completa MFA no proxy. O Evilginx2 interceta tudo em tempo real.
5. O atacante extrai o cookie de sessão e injeta-o no seu próprio browser. Acede ao Microsoft 365 sem MFA.
6. A sessão roubada persiste até expirar ou ser revogada manualmente.

# Exemplo de configuração de um phishlet Evilginx2 (fins educativos)
# NÃO executar em produção — apenas para perceber o vetor de ataque

# Ficheiro: microsoft.yaml (phishlet)
proxy_hosts:
  - {phish_sub: 'login', orig_sub: 'login', domain: 'microsoftonline.com', session: true}
  - {phish_sub: 'www', orig_sub: 'www', domain: 'microsoft.com', session: false}

auth_tokens:
  - domain: '.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'SignInStateCookie']
  - domain: '.microsoft.com'
    keys: ['MSFpc', 'brcap']

credentials:
  username:  {key: 'login', type: 'post', search_in: 'form'}
  password:  {key: 'passwd', type: 'post', search_in: 'form'}

5. Como os Ataques Bypassam MFA

Compreender como o MFA é ultrapassado é fundamental para escolher as defesas adequadas. Existem cinco técnicas principais em 2026:

Técnica	Como funciona	MFA afetado	Defesa recomendada
Reverse proxy (AitM)	Proxy interceta sessão após MFA	Push, TOTP, SMS	FIDO2, Conditional Access session controls
MFA fatigue	Bombardeia push até aprovação	Push	Number matching, additional context, FIDO2
SIM swap	Atacante portabiliza o número e recebe SMS	SMS, Voice	Desativar SMS como MFA; usar app ou FIDO2
Token theft (consent phishing)	App maliciosa obtém access token via OAuth	Todos (bypassa MFA)	Admin consent workflow, app governance, revogação
Session hijacking	Cookie de sessão roubado por malware no endpoint	Todos (bypassa MFA)	Defender for Endpoint, Conditional Access com device compliance

A linha comum a quase todas as técnicas é o token de sessão. O MFA protege a entrada, mas uma vez autenticado, a sessão é representada por um cookie ou token que o browser armazena. Se o atacante obtém esse token — por proxy, por malware no endpoint, por consent phishing — não precisa de MFA. A defesa moderna não é apenas “exigir MFA no login” mas também “proteger e revogar a sessão após o login”.

O FIDO2 (WebAuthn) é o único método de autenticação phishing-resistant por design, porque o desafio criptográfico está vinculado ao domínio real (origin binding). Se o utilizador acede a microsoftonline-login.com (falso), a chave FIDO2 recusa assinar o desafio — o browser verifica a origem. Nenhum dos ataques acima bypassa FIDO2, exceto malware no endpoint que rouba cookies (mitigado por device compliance no Conditional Access).

# Verificar contas que ainda usam SMS como método de autenticação
Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.Read.All"

# Listar todos os utilizadores e os seus métodos de autenticação
$users = Get-MgUser -All -Property Id,DisplayName,UserPrincipalName

foreach ($user in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id
    foreach ($m in $methods) {
        $type = $m.AdditionalProperties["@odata.type"]
        if ($type -match "phone") {
            Write-Output "$($user.UserPrincipalName) usa SMS/Voice (RISCO)"
        }
        if ($type -match "fido2") {
            Write-Output "$($user.UserPrincipalName) tem FIDO2 (RECOMENDADO)"
        }
    }
}

6. Defender para Office 365 (anti-phishing policies)

O Defender para Office 365 inclui políticas anti-phishing que vão muito além dos filtros tradicionais de spam. As políticas anti-phishing analisam spoofing, impersonation de domínios e utilizadores, e características de mensagens para classificar como phishing. Para uma PME portuguesa com Microsoft 365 Business Premium, o Plan 1 já está incluído; o Plan 2 adiciona investigação automatizada e resposta (AIR).

As componentes principais das políticas anti-phishing:

• Spoof intelligence: deteta remetentes que falsificam o domínio FROM (ex: usar @empresa.pt sem autorização). Pode ser configurado para bloquear ou quarentena.
• Impersonation protection: protege contra imitação de utilizadores específicos (ex: CEO, CFO) e domínios confiáveis. O Defender aprende padrões de comunicação e alerta sobre desvios.
• Mailbox intelligence: analisa o padrão de email de cada utilizador para identificar anomalias (ex: um remetente que nunca escreveu para o CFO de repente pede transferência urgente).
• First contact safety tip: mostra um aviso no email quando é a primeira vez que o utilizador recebe de um remetente — útil contra spear phishing de novos domínios.
• QR code detection (Plan 2): analisa imagens anexas à procura de QR codes que apontam para domínios maliciosos.

Para criar uma política anti-phishing completa via PowerShell:

# Conectar ao Exchange Online
Connect-ExchangeOnline

# Criar política anti-phishing com proteção de impersonation
New-AntiPhishPolicy -Name "PhishPolicy-PME" `
    -Enabled $true `
    -EnableFirstContactSafetyTips $true `
    -EnableUnauthenticatedSender $true `
    -EnableViaTag $true `
    -PhishThresholdLevel 2 `
    -ImpersonationProtectionState "On" `
    -EnableTargetedUserProtection $true `
    -TargetedUsersToProtect "[email protected]","[email protected]" `
    -EnableTargetedDomainProtection $true `
    -TargetedDomainsToProtect "empresa.pt" `
    -EnableOrganizationDomainsProtection $true `
    -TargetedUserAction "MoveToJMF" `
    -TargetedDomainAction "MoveToJMF" `
    -MailboxIntelligenceProtectionAction "MoveToJMF" `
    -SpoofQuarantineTag "DefaultPhishingTag"

# Criar regra e aplicar a todos os destinatários
New-AntiPhishRule -Name "PhishRule-PME" `
    -AntiPhishPolicy "PhishPolicy-PME" `
    -RecipientDomainIs "empresa.pt"

Para auditar a política criada e verificar que está ativa:

# Verificar todas as políticas anti-phishing e o seu estado
Get-AntiPhishPolicy | Format-Table Name,Enabled,PhishThresholdLevel,`
    ImpersonationProtectionState -AutoSize

# Verificar regras e domínios a que se aplicam
Get-AntiPhishRule | Format-Table Name,State,Priority,`
    RecipientDomainIs -AutoSize

# Ver configuração detalhada de uma política específica
Get-AntiPhishPolicy -Identity "PhishPolicy-PME" | Format-List

7. Configurar DMARC/SPF/DKIM

DMARC, SPF e DKIM são os três pilares da autenticação de email. Em conjunto, permitem ao destinatário verificar que o email veio realmente do domínio que afirma ser, e não de um atacante a falsificar o endereço FROM. Em 2026, o DMARC em modo p=reject é exigido por muitos provedores de email (Google e Microsoft já aplicam envio para quarentena/rejeição se o domínio não tiver DMARC).

Protocolo	Função	Registo DNS	Nível de proteção
SPF	Lista servidores autorizados a enviar email pelo domínio	TXT	Básico — bloqueia spoofing direto
DKIM	Assina digitalmente cada email com chave privada	TXT (CNAME para Microsoft 365)	Intermédio — garante integridade do conteúdo
DMARC	Define política de ação se SPF/DKIM falham; relatórios	TXT (_dmarc)	Avançado — enforce + telemetria

A configuração deve seguir uma abordagem faseada: começar com p=none para recolher relatórios, depois p=quarantine para mover falhas para spam, e finalmente p=reject para bloquear totalmente. Saltar diretamente para reject sem validar pode bloquear email legítimo.

# ============================================================
# Configuração DMARC/SPF/DKIM para empresa.pt (Microsoft 365)
# ============================================================

# 1. SPF — registo TXT na raiz do domínio
# Lista todos os servidores autorizados a enviar email
empresa.pt.  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# 2. DKIM — ativar no Microsoft 365 via Exchange Online PowerShell
Connect-ExchangeOnline

# Verificar estado atual do DKIM
Get-DkimSigningConfig -Identity empresa.pt | Format-List

# Ativar DKIM para o domínio
Set-DkimSigningConfig -Identity empresa.pt -Enabled $true

# Os CNAMEs necessários no DNS:
# selector1._domainkey.empresa.pt  CNAME  selector1.empresa-pt._domainkey.empresa.onmicrosoft.com
# selector2._domainkey.empresa.pt  CNAME  selector2.empresa-pt._domainkey.empresa.onmicrosoft.com

# 3. DMARC — começar em p=none para recolher relatórios
_dmarc.empresa.pt.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100; ri=86400"

Após 2-4 semanas em p=none, analise os relatórios XML enviados para rua=mailto: com uma ferramenta como o dmarcian ou o parsedmarc open-source. Confirme que não há fontes legítimas a falhar, depois atualize:

# Fase 2: Quarantine (mover falhas para spam)
_dmarc.empresa.pt.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100; ri=86400"

# Fase 3: Reject (bloquear totalmente) — após validação completa
_dmarc.empresa.pt.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100; ri=86400"

# Verificar registo DMARC com dig
dig TXT _dmarc.empresa.pt +short

# Verificar SPF
dig TXT empresa.pt +short

# Verificar DKIM (substituir selector1 se necessário)
dig CNAME selector1._domainkey.empresa.pt +short

8. Conditional Access para Prevenir Phishing

O Conditional Access é a camada que liga identidade, dispositivo, localização e risco. No contexto anti-phishing, as políticas de Conditional Access podem bloquear acessos de localizações suspeitas, exigir dispositivo compliant, revogar sessões persistentes e limitar a duração dos tokens. O artigo sobre Microsoft Entra MFA em 2026 cobre as políticas base; aqui focamo-nos nas políticas especificamente anti-phishing.

As políticas recomendadas para proteção contra phishing moderno:

• Bloquear autenticação legacy: protocolos POP3, IMAP, SMTP, ActiveSync não suportam MFA e são vetores de credential stuffing.
• Exigir device compliance: só dispositivos geridos pelo Intune e compliant podem aceder ao Microsoft 365. Bloqueia sessões roubadas em browsers de atacantes.
• Sign-in frequency control: forçar re-autenticação a cada 4-8 horas em vez de 90 dias. Reduz a janela de exploração de um token roubado.
• Persistent browser session off: não persistir sessões após fecho do browser em dispositivos não geridos.
• Block high-risk sign-ins: usar Identity Protection (P2) para bloquear acessos com risco elevado em tempo real.
• App-enforced restrictions: bloquear download de attachments em browsers não geridos (session controls).

# ============================================================
# Conditional Access: Bloquear autenticação legacy
# Requer Entra ID P1 ou P2 + Microsoft Graph PowerShell SDK
# ============================================================
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Application.Read.All"

# Obter os IDs das aplicações que usam autenticação legacy
$conditions = @{
    ApplicationFilter = @{
        Mode = "exclude"
    }
    ClientAppTypes = @("exchangeActiveSync", "other")
}

$grant = @{
    BuiltInControls = @("block")
    Operator = "OR"
}

$body = @{
    DisplayName = "CA-Block-Legacy-Auth"
    State = "enabled"
    Conditions = @{
        ClientAppTypes = @("exchangeActiveSync", "imap", "pop", "smtp", "other")
        Applications = @{
            IncludeApplications = @("All")
        }
        Users = @{
            IncludeUsers = @("All")
            ExcludeUsers = @("[email protected]")
        }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("block")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $body

# ============================================================
# Conditional Access: Exigir dispositivo compliant + MFA
# ============================================================
$body = @{
    DisplayName = "CA-Require-Compliant-Device-MFA"
    State = "enabled"
    Conditions = @{
        Applications = @{
            IncludeApplications = @("All")
            ExcludeApplications = @("00000000-0000-0000-0000-000000000000")
        }
        Users = @{
            IncludeUsers = @("All")
            ExcludeRoles = @("Global Administrator")
            ExcludeUsers = @("[email protected]")
        }
        ClientAppTypes = @("browser", "mobileAppsAndDesktopClients")
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("compliantDevice", "mfa")
    }
    SessionControls = @{
        SignInFrequency = @{
            Value = 4
            FrequencyInterval = "timeBased"
            AuthenticationType = "primaryAndSecondaryAuthentication"
        }
        PersistentBrowser = @{
            Mode = "never"
        }
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $body

A política acima força três controlos simultâneos: dispositivo tem de estar compliant no Intune, utilizador tem de fazer MFA, sessão expira a cada 4 horas e não persiste após fecho do browser. Isto significa que mesmo que um atacante roube um cookie de sessão, a janela útil é de no máximo 4 horas e o próximo pedido de acesso exigirá MFA num dispositivo que não é o do atacante.

9. Treinar Utilizadores (simulações de phishing)

A tecnologia bloqueia a maioria dos ataques, mas a camada humana continua a ser o último filtro — e o primeiro alvo. A formação de utilizadores não é um workshop anual esquecível; é um programa contínuo com simulações de phishing, feedback imediato e métricas de evolução. A NIS2 exige explicitamente formação em cibersegurança para pessoal com acesso a sistemas.

O Microsoft 365 inclui o Attack simulation training no Defender para Office 365 Plan 2 (disponível no Business Premium). Permite lançar campanhas de phishing simuladas contra os utilizadores, medir quem clica, e atribuir formação automaticamente aos que falham.

# ============================================================
# Criar uma simulação de phishing via PowerShell (Defender)
# Requer Defender para Office 365 Plan 2
# ============================================================
Connect-ExchangeOnline

# Listar payloads de simulação disponíveis
Get-AttackSimulationSimulation -Status Completed | `
    Format-Table Name,Status,AttackTechnique -AutoSize

# Ver utilizadores que clicaram em simulações anteriores
Get-AttackSimulationSimulationUserAction -SimulationId (Get-AttackSimulationSimulation | Select-Object -First 1).SimulationId | `
    Format-Table UserId,ActionType,ActionDateTime -AutoSize

# Relatório de taxa de clique por campanha
Get-AttackSimulationSimulation | `
    Select-Object Name,AttackTechnique,Status,@{N="ClickRate";E={$_.Metrics.ClickRate}} | `
    Format-Table -AutoSize

O programa de formação deve incluir:

• Simulação mensal: um payload diferente por mês (credential harvest, malware attachment, OAuth consent, QR code).
• Feedback imediato: quando o utilizador clica, mostra uma página de explicação em vez de punição. A formação pós-clique é mais eficaz do que workshops genéricos.
• Módulos de formação atribuídos automaticamente: os utilizadores que clicam recebem um módulo de 5-10 minutos específico para o tipo de ataque que falharam.
• Relatório trimestral à direção: taxa de clique, taxa de reporte e evolução por departamento.
• Botão “Reportar Phishing”: implementar o botão de reporte no Outlook (incluído no Defender) para que os utilizadores reportem em vez de ignorar.

Métricas a acompanhar ao longo do tempo:

Métrica	Objetivo	Como medir
Taxa de clique	< 5% (mundo real: 10-15%)	Defender Attack Simulation
Taxa de reporte	> 50% dos suspeitos	Contagem de submissões via botão Reportar
Tempo até reporte	< 5 minutos	Defender submissions log
Repeat clickers	0 (ninguém 3+ vezes seguidas)	Histórico de simulações por utilizador

10. Detectar Phishing com Logs

A detecção de phishing bem-sucedido depende da análise de logs. O Microsoft 365 disponibiliza sign-in logs, audit logs, e logs do Defender no Advanced Hunting (KQL — Kusto Query Language). Para PME com Business Premium, o portal Microsoft Defender oferece queries pré-construídas; com Defender para Office 365 Plan 2 e Microsoft Sentinel, é possível criar regras de deteção customizadas.

Queries KQL para detetar indicadores de phishing bem-sucedido:

// ============================================================
// Query 1: Sign-ins de localizações atípicas (possível token theft)
// Executar no Advanced Hunting (portal Microsoft Defender)
// ============================================================
AADSignInEventsBeta
| where Timestamp > ago(24h)
| where ErrorCode == 0  // sign-in bem-sucedido
| summarize Locais = make_set(Location), Conta = any(AccountDisplayName)
    by AccountUpn
| where array_length(Locais) > 3  // múltiplas localizações em 24h
| project Conta, AccountUpn, Locais

// ============================================================
// Query 2: Sign-ins com MFA satisfeito mas de IP desconhecido
// ============================================================
AADSignInEventsBeta
| where Timestamp > ago(7d)
| where ErrorCode == 0
| where ResultType == 0
| where MFADetail has "MFA completed"
| where IPAddress !in (
    // Lista de IPs conhecidos da empresa (substituir)
    "192.168.1.0","82.154.0.0"
  )
| project Timestamp, AccountUpn, IPAddress, Location, Application, MFADetail
| order by Timestamp desc

// ============================================================
// Query 3: Detetar consent phishing — novas apps OAuth com
// permissões sensíveis concedidas nas últimas 24h
// ============================================================
AADSignInEventsBeta
| where Timestamp > ago(24h)
| where Application != ""
| where AuthenticationRequirement == "MFA completed"
| summarize ConcedidoEm = min(Timestamp), PorUtilizador = make_set(AccountUpn)
    by Application, AppId
| where ConcedidoEm > ago(24h)
| project ConcedidoEm, Application, AppId, PorUtilizador

// ============================================================
// Query 4: Emails reportados como phishing pelos utilizadores
// ============================================================
EmailEvents
| where Timestamp > ago(7d)
| where EmailDirection == "Inbound"
| join kind=inner (
    EmailPostDeliveryEvents
    | where ActionName == "Reported as phishing"
) on NetworkMessageId
| project Timestamp, SenderFromAddress, Subject, RecipientEmailAddress, ReportTime
| order by ReportTime desc

// ============================================================
// Query 5: Sessões persistentes de IPs não corporativos
// Indicador de token roubado via Evilginx2
// ============================================================
AADSignInEventsBeta
| where Timestamp > ago(7d)
| where ErrorCode == 0
| where ClientAppUsed =~ "Browser"
| where IPAddress !startswith "192.168."
| where IPAddress !startswith "10."
| where AuthenticationRequirement == "MFA completed"
| summarize Sessoes = count(), IPs = make_set(IPAddress)
    by AccountUpn
| where Sessoes > 10
| project AccountUpn, Sessoes, IPs
| order by Sessoes desc

11. Responder a um Incidente de Phishing

Quando um phishing é bem-sucedido — um utilizador clicou, introduziu credenciais, ou aprovou consentimento OAuth — a resposta tem de ser rápida e coordenada. Os primeiros 60 minutos determinam se o incidente fica num acesso isolado ou escala para comprometimento total do inquilino. A NIS2 exige que incidentes significativos sejam notificados à autoridade nacional (CNPD em Portugal) em 24 horas.

Plano de resposta a incidente de phishing (os primeiros 60 minutos):

1. Isolar (0-5 min): revogar todas as sessões do utilizador comprometido imediatamente.
2. Repor password (5-10 min): forçar reset de password e exigir re-registo de todos os métodos de MFA.
3. Auditar (10-30 min): verificar sign-in logs, audit logs, regras de inbox, delegações de mailbox, consentimentos OAuth e apps registadas pelo utilizador.
4. Remover acesso malicioso (30-45 min): revogar consentimentos OAuth suspeitos, remover regras de forwarding de inbox criadas pelo atacante.
5. Comunicar (45-60 min): notificar direção, equipa de segurança e, se dados pessoais estiverem comprometidos, iniciar processo RGPD/CNPD.

# ============================================================
# Resposta a incidente: revogar sessões e isolar utilizador
# ============================================================
Connect-MgGraph -Scopes "User.ReadWrite.All","UserAuthenticationMethod.ReadWrite.All"

$UserUpn = "[email protected]"

# 1. Revogar TODAS as sessões (refresh tokens incluídos)
Revoke-MgUserSignInSession -UserId $UserUpn

# 2. Reset de password (gerar temporária)
$newPassword = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 24 | % {[char]$_})
Update-MgUser -UserId $UserUpn -PasswordProfile @{
    Password = $newPassword
    ForceChangePasswordNextSignIn = $true
}
Write-Output "Nova password temporaria: $newPassword"

# 3. Exigir re-registo de todos os métodos de MFA
Update-MgUser -UserId $UserUpn -StrongAuthenticationRequirements @{
    RelyingParty = "*"
    State = "enforced"
}

# 4. Verificar consentimentos OAuth concedidos pelo utilizador
Get-MgUserOauth2PermissionGrant -UserId $UserUpn | `
    Format-Table ClientId,Scope,ConsentType -AutoSize

# ============================================================
# Verificar e remover regras de forwarding criadas pelo atacante
# ============================================================
Connect-ExchangeOnline

# Listar regras de inbox do utilizador
Get-InboxRule -Mailbox $UserUpn | `
    Format-Table Name,RedirectTo,ForwardTo,DeleteMessage -AutoSize

# Remover regras suspeitas (substituir "NomeDaRegra" pelo nome real)
Remove-InboxRule -Mailbox $UserUpn -Identity "NomeDaRegraSuspeita" -Force

# Verificar delegações de mailbox
Get-MailboxPermission -Identity $UserUpn | `
    Where-Object { $_.User -ne "NT AUTHORITY\SELF" -and $_.IsInherited -eq $false }

# Remover delegações suspeitas
Remove-MailboxPermission -Identity $UserUpn `
    -User "[email protected]" `
    -AccessRights FullAccess -InheritanceType All -Force

# ============================================================
# Revogar consentimentos OAuth maliciosos concedidos
# ============================================================
Connect-MgGraph -Scopes "DelegatedPermissionGrant.ReadWrite.All"

# Listar todas as concessões OAuth do utilizador
Get-MgUserOauth2PermissionGrant -UserId $UserUpn | ForEach-Object {
    $appId = $_.ClientId
    $app = Get-MgApplication -Filter "appId eq '$appId'" -ErrorAction SilentlyContinue
    Write-Output "App: $($app.DisplayName) | Scope: $($_.Scope) | ID: $($_.Id)"
}

# Revogar concessão OAuth específica (substituir pelo GrantId)
Remove-MgUserOauth2PermissionGrant -OAuth2PermissionGrantId ""

# Revogar todas as concessões de um utilizador específico (cuidado em produção)
Get-MgUserOauth2PermissionGrant -UserId $UserUpn | ForEach-Object {
    Remove-MgUserOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id
    Write-Output "Revogado: $($_.ClientId)"
}

12. Ferramentas Open-Source Anti-Phishing

Para além das soluções Microsoft, existe um ecossistema de ferramentas open-source que complementam a defesa anti-phishing. São particularmente úteis para PME com orçamento limitado que querem camadas adicionais de análise e formação.

Ferramenta	Função	Caso de uso
PhishTool	Análise de emails de phishing	Extrair headers, URLs e anexos para triagem manual
parsedmarc	Parser de relatórios DMARC	Visualizar relatórios XML DMARC em Elasticsearch/Kibana
Gophish	Simulação de phishing	Campanhas de formação para equipas sem Defender Plan 2
urlscan.io	Análise de URLs suspeitos	Verificar se um link é malicioso antes de clicar (sandbox)
AbuseIPDB	Reputação de IPs	Verificar se IP de sign-in está reportado como malicioso
VirusTotal	Análise de ficheiros e URLs	Submeter anexos suspeitos para análise multi-AV
SysReptor (com parsedmarc)	Relatórios de pentest/phishing	Documentar incidentes de phishing profissionalmente

O Gophish é particularmente interessante para PME que não têm Defender para Office 365 Plan 2: permite montar campanhas de simulação de phishing self-hosted com templates personalizáveis e métricas de clique, reporte e submissão de formação.

# Instalar Gophish em Linux (Debian/Ubuntu) para simulações
# Descarregar a última versão
wget https://github.com/gophish/gophish/releases/download/v0.12.1/gophish-v0.12.1-linux-64bit.zip
unzip gophish-v0.12.1-linux-64bit.zip -d gophish
cd gophish

# Editar config.json com o domínio e porta desejados
# "admin_url": "https://simulacao.empresa.pt:3333"
# "phish_url": "https://phish.empresa.pt"

# Gerar certificados TLS com Let's Encrypt
certbot certonly --standalone -d simulacao.empresa.pt -d phish.empresa.pt

# Copiar certificados para o diretório do Gophish
cp /etc/letsencrypt/live/simulacao.empresa.pt/fullchain.pem .
cp /etc/letsencrypt/live/simulacao.empresa.pt/privkey.pem .

# Iniciar o Gophish
chmod +x gophish
./gophish

# Aceder ao painel de administração
# https://localhost:3333 (credenciais no ficheiro gophish.db inicial)

13. Boas Práticas para PMEs

As PME portuguesas enfrentam um dilema: têm os mesmos ataques que as grandes empresas, mas com uma fracção dos recursos. A boa notícia é que o Microsoft 365 Business Premium, que muitas PME já subscrevem, inclui quase todas as ferramentas necessárias. O desafio é configurá-las. As seguintes boas práticas são especificamente calibradas para PME com 10 a 300 utilizadores.

• Ativar Security Defaults se não houver Conditional Access: é a defesa mínima gratuita que obriga MFA para todos. Não é ideal, mas é infinitamente melhor que nada.
• Migrar para Conditional Access assim que possível: com licença P1 (incluída no Business Premium), substituir Security Defaults por policies granulares com device compliance e session controls.
• FIDO2 para contas administrativas: gastar 30-50 euros numa chave YubiKey para cada conta de administrador elimina o maior risco. É o investimento com melhor relação custo-benefício em segurança.
• DMARC em p=reject: impede spoofing do domínio da empresa e melhora a entregabilidade de email legítimo. Custa zero — é apenas configuração DNS.
• Ativar todas as políticas anti-phishing do Defender: spoof intelligence, impersonation, first contact safety tip. Não é opcional — está incluído na licença.
• Simulações mensais: usar o Attack Simulation Training incluído no Defender. Uma simulação por mês com formação atribuída aos que falham.
• Implementar o botão “Reportar Phishing”: o Defender inclui um add-in para Outlook que coloca um botão na barra de ferramentas. Ative-o via política para todos os utilizadores.
• Bloquear autenticação legacy: via Conditional Access. É a política com maior impacto e menor esforço — bloqueia IMAP, POP, ActiveSync sem MFA.
• Configurar alertas de sign-in para contas privilegiadas: qualquer login de Global Admin deve gerar alerta imediato.
• Documentar o plano de resposta: ter um runbook com os comandos PowerShell de revogação prontos para copiar-colar. Num incidente real, não há tempo para procurar documentação.

O investimento total para uma PME com 50 utilizadores e Microsoft 365 Business Premium: zero euros adicionais. O custo está apenas no tempo de configuração — estimado em 8-16 horas para implementar todas as camadas descritas neste artigo. O ROI é imediato: a probabilidade de um incidente de phishing bem-sucedido cai de ~15% para < 2%.

14. Checklist Anti-Phishing

Checklist completo de implementação anti-phishing para uma PME com Microsoft 365. Imprima, marque cada item e repita trimestralmente.

Identidade e MFA

• ☐ MFA ativo para todos os utilizadores (Security Defaults ou Conditional Access).
• ☐ Number matching e additional context ativos no Microsoft Authenticator.
• ☐ SMS e Voice desativados como métodos de MFA (se possível).
• ☐ FIDO2 habilitado e distribuído a todas as contas administrativas.
• ☐ Break-glass accounts criadas, guardadas em cofre físico, com alertas de sign-in.
• ☐ Temporary Access Pass configurado para recuperação de MFA.

Email e Defender

• ☐ Política anti-phishing criada com impersonation e spoof intelligence.
• ☐ First contact safety tip ativado.
• ☐ QR code detection ativado (Plan 2).
• ☐ Botão “Reportar Phishing” implementado no Outlook de todos os utilizadores.
• ☐ SPF configurado com -all (hard fail).
• ☐ DKIM ativado para todos os domínios de email.
• ☐ DMARC em p=reject após fase de monitorização.

Conditional Access

• ☐ Autenticação legacy bloqueada (POP, IMAP, SMTP, ActiveSync).
• ☐ Device compliance exigido para acesso ao Microsoft 365.
• ☐ Sign-in frequency control: re-autenticação a cada 4-8 horas.
• ☐ Persistent browser session desativada em dispositivos não geridos.
• ☐ Contas administrativas: MFA sempre, sem trusted location, sem exclusões.
• ☐ Todas as policies testadas em report-only antes de enabled.

Formação e Simulação

• ☐ Simulação de phishing mensal com payload rotativo.
• ☐ Formação automática atribuída a utilizadores que clicam.
• ☐ Relatório trimestral de taxa de clique e reporte à direção.
• ☐ Runbook de resposta a incidente documentado e testado.

Monitorização e Resposta

• ☐ Queries KQL de Advanced Hunting configuradas e executadas semanalmente.
• ☐ Alertas de sign-in suspeito configurados (localização atípica, MFA fora de horas).
• ☐ Comandos PowerShell de revogação de sessão e reset prontos (runbook).
• ☐ Procedimento de notificação CNPD/RGPD documentado (prazo 24h).
• ☐ Revisão trimestral de políticas, métodos e break-glass accounts agendada.

Referências externas

• Anti-phishing policies in Defender for Office 365 — learn.microsoft.com
• Impersonation protection — learn.microsoft.com
• Evilginx2 — GitHub
• DMARC.org — especificação e recursos
• Attack simulation training — learn.microsoft.com
• Conditional Access overview — learn.microsoft.com
• CISA — Phishing guidance
• CNPD — Comissão Nacional de Proteção de Dados (Portugal)
• Advanced Hunting with KQL — learn.microsoft.com
• Gophish — Open-source phishing simulation