quot; | where base_domain != "suaempresa.com.br" AND (like(sender_domain, "%suaempresa%") OR like(sender_domain, "%sua-empresa%")) | table _time, sender_domain, sender_email, recipient, subject | sort -_time ``` ### SPL - Splunk - Volume Anômalo de E-mail Saindo de uma Conta (exfiltração) ```spl // [VALIDAR NO SEU AMBIENTE] // Detecta contas enviando volume anormalmente alto de e-mails (possível spam/BEC relay) index=email sourcetype=mail_log action=sent | stats count AS emails_sent by sender_email, daté_hour | eventstats avg(emails_sent) AS avg_sent, stdev(emails_sent) AS std_sent by sender_email | where emails_sent > (avg_sent + 3*std_sent) AND emails_sent > 50 | table daté_hour, sender_email, emails_sent, avg_sent | sort -emails_sent ``` ### SPL - Splunk - Acesso a Caixa Postal Fora do Horário Comercial (BEC lateral) ```spl // [VALIDAR NO SEU AMBIENTE] // Detecta acessos a e-mail corporativo entre 22h e 06h — indicativo de ATO index=o365 sourcetype=o365:management:activity Operation=MailItemsAccessed | eval hour=strftime(_time, "%H") | where hour >= 22 OR hour < 6 | stats count AS laté_access_count, values(ClientIPAddress) AS ips by UserId, daté_mday | where laté_access_count > 10 | sort -laté_access_count ``` --- ## Contenção > [!danger] Execute na ordem exata — cada passo depende do anterior. Em caso de BEC com transação financeira em andamento, execute o passo "Contatar banco" ANTES de qualquer outro. - [ ] **T+0** - Se suspeita de transferência fraudulenta em curso: ligar imediatamente para o banco (número de emergência do gerente de conta ou central de fraudes). Jánela de reversão via PIX é de **30 minutos**. - [ ] **T+5min** - Confirmar comprometimento de conta via logs de autenticação (Entra ID / Google Admin) - [ ] **T+5min** - Declarar incidente P1 e acionar IR lead e CISO via canal seguro (Signal/telefone) - [ ] **T+10min** - Desabilitar a(s) conta(s) comprometida(s) no IdP (Entra ID / Okta / Google Admin) - **NÃO apenas resetar senha, desabilitar completamente** - [ ] **T+10min** - Revogar todos os tokens de acesso e sessões ativas: - M365: `Revoke-AzureADUserAllRefreshToken -ObjectId $userId` - Google: Admin Console → Users → Reset Sign-in Cookies - Okta: Admin → User → More Actions → Clear User Sessions - [ ] **T+15min** - Revogar todos os grants OAuth concedidos pela conta comprometida: - M365: `Get-AzureADUserOAuth2PermissionGrant -ObjectId $userId | Remove-AzureADOAuth2PermissionGrant` - Google: Admin Console → Users → Security → App access - [ ] **T+15min** - Colocar em quarentena todos os e-mails phishing identificados no gateway (Microsoft Defender / Proofpoint / Mimecast) - usar Message Trace para localizar todos os destinatários - [ ] **T+20min** - Bloquear domínios de phishing identificados no gateway de e-mail e no proxy/firewall - [ ] **T+25min** - Verificar e desabilitar regras de inbox maliciosas: ```powershell Get-InboxRule -Mailbox [email protected] | Where-Object {$_.Enabled -eq $true} | Format-List Name, ForwardTo, DeleteMessage, ForwardAsAttachmentTo ``` - [ ] **T+30min** - Verificar se forwarding externo está ativo: ```powershell Get-Mailbox -Identity [email protected] | Select ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward ``` - [ ] **T+30min** - Identificar todos os e-mails enviados pela conta comprometida nas últimas 72h e verificar se contêm solicitações de pagamento ou alterações de dados bancários - [ ] **T+45min** - Notificar áreas de negócio que tenham recebido e-mails do remetente comprometido nas últimas 72h - verificar se houve ação financeira - [ ] **T+1h** - Acionar jurídico/DPO para avaliação LGPD - [ ] **T+1h** - Preservar todos os logs para uso forense: Unified Audit Log (M365), Admin Audit (Google), IdP Sign-in Logs --- ## Erradicação - [ ] Remover **todas** as regras de inbox criadas durante o período comprometido (não apenas as identificadas como maliciosas) - [ ] Remover delegações de caixa postal não autorizadas (`Remove-MailboxPermission`) - [ ] Revogar e remover todos os apps OAuth concedidos que não estejam na whitelist corporativa aprovada - [ ] Auditar e remover endereços de forwarding externo em todas as caixas postais da organização (não apenas a comprometida): ```powershell Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ForwardingSmtpAddress -ne $null} | Select UserPrincipalName, ForwardingSmtpAddress ``` - [ ] Resetar senha da conta comprometida com senha forte gerada aleatoriamente (mínimo 20 caracteres) - [ ] Forçar habilitação de MFA resistente a phishing na conta comprometida antes de reativar ([[t1110-brute-force|T1110 - Brute Force]] via credential stuffing é frequente após um ATO) - [ ] Verificar se o atacante criou contas de e-mail adicionais ou aliases na organização - [ ] Verificar se a conta foi adicionada a grupos de distribuição ou listas de acesso a recursos sensíveis durante o período comprometido - [ ] Auditar logs do ERP / sistema financeiro para verificar alterações de dados bancários de fornecedores nas últimas 72h - [ ] Verificar se logins na conta comprometida foram usados para acessar outros sistemas integrados (SSO - VPN, SharePoint, GitHub, Salesforce, ERP) - [ ] Aplicar Conditional Access Policy com requisito de device compliance na conta antes de reativar - [ ] Fechar o vetor de entrada: se o comprometimento veio de um link de phishing - adicionar domínio à lista de bloqueio e reportar ao Microsoft/Google para remoção --- ## Recuperação - [ ] Reativar conta apenas após: senha resetada + MFA habilitado + sessions revogadas + OAuth limpo + regras removidas - [ ] Habilitar auditoria de mailbox (`Set-Mailbox -AuditEnabled $true -AuditLogAgeLimit 180`) na conta afetada e nas vizinhas - [ ] Configurar alertas específicos no SIEM para a conta recuperada: qualquer novo grant OAuth, nova regra de inbox, novo forwarding, acesso de novo país - [ ] Conduzir sessão de conscientização com o usuário afetado (não punitiva - foco em treinamento): - Como identificar phishing de consentimento OAuth - Como reportar e-mails suspeitos corretamente - Por que MFA push não é suficiente - orientar sobre FIDO2/Passkey - [ ] Comúnicar ao usuário os procedimentos corretos para verificar solicitações financeiras urgentes (confirmação por telefone no número cadastrado, nunca por e-mail) - [ ] Verificar se há cobranças fraudulentas em serviços cloud associados à conta (Azure, GCP, AWS se havia credenciais armazenadas) - [ ] Monitoramento intensivo de 30 dias na conta recuperada e nas contas com as quais ela interagiu - [ ] Se dados pessoais foram exfiltrados: avaliar necessidade de comunicação a titulares (LGPD Art. 48) - [ ] Documentar IoCs (domínios, IPs, hashes) e submeter ao MISP / OpenCTI para enriquecimento compartilhado --- ## Lições Aprendidas - Templaté de Post-Mortem ### Cronologia do Incidente | Evento | Data/Hora | Responsável | |--------|-----------|-------------| | E-mail phishing recebido (TTD retroativo) | | | | Usuário clicou no link / abriu anexo | | | | Credenciais comprometidas (login do atacante) | | | | Regras maliciosas criadas | | | | Alerta gerado no SIEM/CASB | | | | Confirmação de comprometimento | | | | Declaração de incidente P1 | | | | Contenção completa (conta desabilitada) | | | | Erradicação concluída | | | | Recuperação completa | | | ### Métricas de Impacto | Métrica | Valor | |---------|-------| | Tempo de dwell (acesso antes da detecção) | | | MTTD - Mean Time to Detect | | | MTTC - Mean Time to Contain | | | MTTR - Mean Time to Recover | | | Número de contas comprometidas | | | Volume estimado de e-mails lidos pelo atacante | | | Valor financeiro fraudado (se BEC) | | | Valor recuperado (se BEC) | | | Custo total do incidente (R$) | | ### Questões Obrigatórias 1. Como o e-mail phishing passou pelos filtros do gateway? (SPF/DKIM/DMARC configurados corretamente?) 2. Por que o usuário interagiu com o e-mail? Falta de treinamento? E-mail muito convincente? 3. O MFA estava habilitado na conta? Se sim, como foi bypassado? (Consent phishing? MFA fatigue? AiTM proxy?) 4. As regras de inbox maliciosas foram criadas imediatamente após o login? Por quanto tempo estiveram ativas? 5. Havia alertas CASB ou SIEM configurados para detectar forwarding externo e OAuth grants anômalos? 6. A Conditional Access Policy bloqueou o login de localização atípica? 7. Houve impacto financeiro? A janela de bloqueio junto ao banco foi respeitada? 8. O playbook foi eficaz? O que precisa ser atualizado? ### Melhorias Recomendadas - [ ] Implementar MFA resistente a phishing (FIDO2 / Passkey) para todos os usuários com acesso a sistemas financeiros - [ ] Configurar políticas de Conditional Access bloqueando logins de países não operacionais - [ ] Habilitar alertas automáticos para criação de regras de forwarding externo (Microsoft Defender for Cloud Apps / Google Alert Center) - [ ] Implementar DMARC com política `p=reject` no domínio corporativo - [ ] Rever e restringir quais apps OAuth podem receber consentimento de usuários (Tenant-level app consent policy) - [ ] Implementar processo formal de verificação para solicitações de alteração de dados bancários de fornecedores (dupla aprovação + telefonema de confirmação) - [ ] Exercício de simulação de phishing semestral com todos os colaboradores - [ ] Configurar proteção anti-spoofing e anti-impersonation no gateway de e-mail --- ## Contexto LATAM/Brasil > [!info] Contexto Regional > Ataques de phishing e BEC no Brasil têm características específicas que diferenciam o cenário local do global. Conhecer esses padrões é essencial para calibrar as detecções. ### Fraude via PIX no Contexto Corporativo O PIX transformou o panorama de fraudes financeiras no Brasil desde 2020. Em ataques de BEC direcionados a empresas brasileiras: - **Velocidade é o fator crítico**: uma transferência PIX é liquidada em segundos e tem reversão impossível após a confirmação. A janela de ação do time de resposta é dramaticamente menor do que em fraudes via TED/DOC - **Mecanismo de devolução PIX**: o SPI (Sistema de Pagamentos Instantâneos) do Banco Central tem um mecanismo de devolução (`MED - Mecanismo Especial de Devolução`), mas requer ação imediata do banco do pagador. A conta recebedora frequentemente é uma laranjá que saca o valor em minutos - **Engenharia social via WhatsApp**: o BEC brasileiro frequentemente migra para WhatsApp após o e-mail inicial - o "CFO" solicita a transferência por WhatsApp usando conta clonada - **PIX de alto valor via chave CNPJ**: atacantes criam CNPJs "fantasma" com chave PIX para receber pagamentos B2B sem levantar suspeita imediata ### LGPD - Obrigações de Notificação Conforme o Art. 48 da Lei Geral de Proteção de Dados Pessoais (LGPD — Lei 13.709/2018): - O controlador deve notificar a **ANPD** e os titulares afetados em caso de incidente de segurança que possa acarretar risco ou dano relevante - Prazo: **razoável** (interpretado como até 72h pela ANPD, alinhado ao GDPR) - Comprometimento de caixas postais corporativas geralmente envolve dados pessoais de clientes, funcionários e terceiros - ativa a obrigação de notificação - Notificação deve conter: data do incidente, natureza dos dados, medidas de segurança adotadas, riscos relacionados, medidas para reverter ou mitigar o incidente - Portal de notificação: https://www.gov.br/anpd/pt-br ### CERT.br - Reporte de Incidentes O CERT.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil) é o CSIRT nacional: - **Reporte obrigatório** de incidentes envolvendo infraestrutura crítica nacional - **Recomendado** para qualquer incidente com impacto significativo ou IoCs que possam beneficiar a comunidade - E-mail de reporte: `[email protected]` (com PGP disponível) - Portal: https://www.cert.br/ - Taxonomia usada: eCSIRT.net (alinhada com ENISA) ### Padrões de Phishing em Português Ataques direcionados ao Brasil utilizam português brasileiro com qualidade crescente (uso de IA generativa para redigir e-mails convincentes). Padrões recorrentes: | Tema | Pretexto Comum | Alvo | |------|---------------|------| | Phishing Fiscal | "Nota Fiscal pendente", "NF-e rejeitada pela SEFAZ" | Área financeira e contábil | | Phishing Bancário Corporativo | "Atualização de segurança obrigatória", "Acesso bloqueado" | Tesouraria, área financeira | | CEO Fraud em PT-BR | "Operação confidencial - transferência urgente" | Tesouraria, diretoria financeira | | Phishing Judicial | "Citação judicial - prazo improrrogável" | Jurídico, gestores | | Phishing LGPD/ANPD | "Seu CNPJ foi autuado por violação à LGPD" | DPOs, jurídico | | Phishing Correios/SEDEX | "Pacote retido - taxa de importação" | Qualquer colaborador | ### Setores Mais Impactados no Brasil O setor **financeiro** (bancos, fintechs, seguradoras, corretoras) é o principal alvo de BEC no Brasil, seguido de: - **Agronegócio** - alto volume de transações B2B e uso de e-mail como canal primário de negociação - **Saúde** - hospitais e operadoras de plano com dados sensíveis de pacientes - **Governo e órgãos públicos** - alvo de spear-phishing de grupos de espionagem regional (grupos APT vinculados a países vizinhos) - **Varejo e e-commerce** - fraude de fornecedores e marketplace fraud --- ## Referências - [[t1566-phishing|T1566 - Phishing]] - técnica MITRE ATT&CK (vetor primário) - [[t1566-001-spearphishing-attachment|T1566.001 - Spearphishing Attachment]] - sub-técnica de anexo malicioso - [[t1566-002-spearphishing-link|T1566.002 - Spearphishing Link]] - sub-técnica de link de phishing - [[t1534-internal-spearphishing|T1534 - Internal Spearphishing]] - phishing interno via conta comprometida - [[t1114-email-collection|T1114 - Email Collection]] - coleta de e-mails por atacante com acesso ao mailbox - [[t1078-valid-accounts|T1078 - Valid Accounts]] - uso de credenciais legítimas pós-comprometimento - [[t1098-account-manipulation|T1098 - Account Manipulation]] - manipulação de conta (regras, forwarding, OAuth) - [[t1110-brute-force|T1110 - Brute Force]] - força bruta de credenciais e credential stuffing - [[g1015-scattered-spider]] - grupo que usa phishing de consentimento OAuth e MFA fatigue extensivamente - [[silent-ransom-group]] - grupo de BEC e extorsão sem ransomware com foco em dados e movimentações financeiras - [MITRE ATT&CK - Phishing](https://attack.mitre.org/techniques/T1566/) - [NIST SP 800-61 Rev. 2 - Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) - [FBI IC3 - 2023 Internet Crime Report (BEC)](https://www.ic3.gov/Media/PDF/AnnualReport/2023_IC3Report.pdf) - [CERT.br - Práticas de Segurança para Administradores de Redes](https://www.cert.br/docs/seg-adm-redes/) - [ANPD - Guia Orientativo para Notificações de Incidentes de Segurança](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/guia-orientativo-para-notificacoes-de-incidentes-de-segurança.pdf) - [Microsoft - Resposta a Ataques de BEC](https://www.microsoft.com/en-us/security/blog/2023/05/24/business-email-compromise/) - [CISA - Business Email Compromise Guide](https://www.cisa.gov/sites/default/files/publications/Business_Email_Compromise_Guide_508.pdf) --- *Última revisão: 2026-03-26 | Próxima revisão recomendada: 2026-09-26*