SIM Swap em empresas brasileiras: estudos de caso
SIM Swap em empresas brasileiras: estudos de caso
Atualizado em: 2026-10
O que você vai aprender:
- Como SIM swap funciona tecnicamente e quais vetores os atacantes usam contra empresas brasileiras.
- Como mapear superfície de ataque, detectar sinais iniciais e implementar controles técnicos e organizacionais.
- Playbooks operacionais completos para Blue Team e Red Team, métricas e checklists de auditoria aplicáveis a SOCs e equipes de segurança.
Pré-requisitos: conhecimentos em redes, telecom, autenticação multifator, operação de SOC/SIEM e procedimentos de resposta a incidentes.
Nível: intermediário | avançado
Sumário:
- Contexto Atual e Relevância Estratégica
- Fundamentos Técnicos do Tema
- Arquitetura, Fluxos e Superfície de Ataque
- Cenários Reais e Estudos de Caso
- Implementação Prática Step-by-Step
- Hardening, Controles e Melhores Práticas
- Playbooks Operacionais para Blue Team e Red Team
- Métricas, KPIs e Auditoria Técnica
- Erros Comuns, Armadilhas e Correções
- FAQ Técnico para Busca Orgânica
- Considerações Finais
- Referências
Em 2025, uma fintech brasileira com 2,3 milhões de contas registrou perda de acesso massiva e transações fraudulentas após uma onda coordenada de SIM swap que explorou falhas operacionais em processos de portabilidade e recuperação de contas. Neste artigo você verá, com detalhe técnico e pragmático, como esses ataques ocorrem, quais erros comuns permitem escalar da fraude básica para comprometer contas corporativas, como detectar atividades precoces no SIEM e que controles implementar para reduzir risco residual a níveis operacionais aceitáveis.
Contexto Atual e Relevância Estratégica
Panorama global e impacto no Brasil
O SIM swap deixou de ser um golpe de nicho para consumidores e evoluiu para vetor estratégico contra empresas, bancos e provedores de serviços. Desde 2024 observou-se aumento de campanhas organizadas que combinam engenharia social contra operadoras, compra de dados de identidade em mercados ilícitos e uso de scripts para automação de requisições de portabilidade. Risco de negócio: perda direta de fundos, responsabilidade regulatória, danos reputacionais e operação de conta bloqueada.
Atacar a telemetria de recuperação (SMS, chamadas de voz) é frequentemente mais lucrativo para o atacante que explorar vulnerabilidades de sofware, devido à combinação de baixo custo e alto retorno quando o processo de onboarding depende de número de celular como fator primário.
Contexto regulatório e operacional no Brasil
A ANATEL e o Marco Civil definem obrigações sobre identidade do assinante e responsabilidade das prestadoras; em 2025-2026 houve pressão regulatória por controles contra fraudes de portabilidade e autenticação. Para empresas que usam SMS como segundo fator, mudança regulatória sobre registro de assinante e requisitos de portabilidade podem reduzir risco, mas somente se operacionalizados via contrato com operadores e monitoramento contínuo.
Sem cláusulas contratuais de SLAs específicos para “bloqueio por suspeita de SIM swap” e APIs de verificação, empresas ficam vulneráveis mesmo com boas práticas internas.
Dados e tendências recentes
Indicadores observados por equipes de threat intelligence em 2025 mostraram aumento de 42% em tentativas de portabilidade fraudulenta vinculadas a credenciais vazadas em leaks. Métricas relevantes para executivos: tempo médio de detecção (MTTD) de SIM swap em incidentes reais foi 6-12 horas quando apenas logs de autenticação eram monitorados; com detecção proativa via sinais de telecom esse MTTD caiu para <4 horas.
1 2 3 4 5 6 7 8 | Fluxo de incidentes observados: 1) Compra de identidade em mercado ilícito 2) Reconhecimento - confirmação de operadora e carrier code 3) Contato com call center ou uso de portabilidade online 4) Requisição de portabilidade ou reemissão de SIM 5) Ativação do novo SIM pelo atacante 6) Recuperação de contas via OTP por SMS/voz 7) Transferência de fundos ou takeover de serviços |
Fundamentos Técnicos do Tema
O que é SIM swap tecnicamente
SIM swap é o processo pelo qual o número de telefone é movido de um chip (SIM) para outro, geralmente com autorização aparente do titular. Tecnicamente envolve alteração de apontamento no HLR/HSS da operadora ou processo de portabilidade entre PLMN, seguido pela atualização de registros IMSI/IMSI attach para o novo equipamento. Um atacante que obtenha controle do MSISDN passa a receber OTPs por SMS e chamadas, permitindo takeover de contas que dependem desse canal.
1 2 3 4 5 6 7 8 9 10 11 | +---------------------------+ | Camada de decisão (policy)| +---------------------------+ | +---------------------------+ | Controles e lógica | +---------------------------+ | +---------------------------+ | Telemetria e evidência | +---------------------------+ |
Vetores usados por atacantes
Os vetores mais comuns observados incluem: engenharia social com call centers de operadora, falsificação de documentos, compra de SIM pré-ativado de golpe, exploração de portais de autoatendimento com falhas de verificação, e mecanismos de cooptação de funcionários de operadora. Cada vetor tem trade-offs entre custo, complexidade e taxa de sucesso; operação de fraude que envolve cooptação interna tem custo maior mas taxa de sucesso pode exceder 70% em amostras analisadas.
Modelos de autenticação fragilizados pelo SMS
Modelos OTP via SMS são vulneráveis a interceptação e SIM swap. Senhas estáticas e MFA por SMS deveriam ser classificadas como fracas em matrizes de risco. NIST e boa prática do mercado já recomendam migrar para autenticadores TOTP, FIDO2/webauthn ou certificados. Empresas que mantêm SMS devem aplicar mitigantes: detecção de portabilidade, verificação de device fingerprint e políticas de bloqueio para mudanças de número.
| Controle | Mecanismo | Prós | Contras |
|---|---|---|---|
| Substituir SMS por Authenticator | TOTP / WebAuthn | Resistente a SIM swap, offline | Requer onboarding e suporte ao usuário |
| Verificação ativa de portabilidade | API com operadora para checagem de histórico | Detecção precoce de trocas | Depende de integração e SLAs |
| Proteção de recuperação de conta | Passos adicionais – KBA, validação documental | Reduz ataques automatizados | Risco de false positives e atrito UX |
| Rate limit de requisições de MFA | Bloqueio temporário após tentativas | Diminui automação de ataques | Pode bloquear usuários legítimos |
Telecom 101 para defenders
Entender Mobile Network Codes (MNC), Mobile Country Code (MCC), IMSI, MSISDN, HLR/HSS, VLR e protocols como SS7 e Diameter é essencial. Interceptação por SS7 é uma via diferente do SIM swap, mas combinada pode permitir interceptação sem nova SIM; defendê-las requer contratos de roaming e monitoramento de signaling anômalo com parceiros de telecom.
Peça na sua equipe jurídica um adendo contratual com operadoras para “notificação imediata de portabilidade suspeita” e definição de canais técnicos para checagens via API.
Arquitetura, Fluxos e Superfície de Ataque
Como mapear a superfície de ataque nas empresas
Mapear superfície começa por inventariar dependências que usam MSISDN: MFA, onboarding, suporte/recuperação, notificações, APIs com validação por SMS, integração com provedores de identidade e fornecedores de telecom. Para cada dependência, documente: SOPs de recuperação, pontos de automação, criticidade e controles compensatórios. Resultado prático: matriz de risco que prioriza 10-15 ativos que exigem mitigação imediata.
| Ativo | Uso do MSISDN | Risco primário | Mitigação recomendada |
|---|---|---|---|
| Portal de clientes | MFA via SMS | Account takeover | WebAuthn + verificação de portabilidade |
| Recuperação de senha | Token por SMS | Recuperação fraudulenta | Checks adicionais KBA + documento |
| Operações bancárias | Notificações e OTP | Transferência fraudulenta | Autenticação forte e bloqueio transacional |
| Suporte telefônico | Confirmação de identidade | Engenharia social | Script rígido e verificação multi-fator |
Fluxo de ataque técnico – visão detalhada
1 2 3 4 5 6 7 8 9 | Fluxo técnico do ataque SIM swap (detalhado): 1) Reconhecimento: coleta MSISDN, nome, CPF, data de nascimento, operadora alvo 2) Enriquecimento: cruzamento com leaks para validar identidades 3) Preparação: aquisição de ferramenta de portabilidade ou cooptação de agente 4) Execução portabilidade: submissão de pedido via portal ou call center 5) Atualização HLR/HSS: nova associação IMSI/MSISDN no novo SIM 6) Ativação de sessão: atacante recebe OTP/voz 7) Post-compromise: takeover de contas, alteração de e-mail, reset de 2FA 8) Remoção de rastros: alteração de logs de autenticação, uso de VPNs |
Superfície de ataque por camada
Divida a superfície em camadas: administrativo (SOPs, contratos), humano (suporte, agentes), técnico (APIs, autenticação), telecom (integração com operadores) e legal/regulatório. A defesa deve tratar cada camada com controles quantificáveis. Trade-off típico: controles mais rígidos aumentam FRR (false rejection rate) e atrito do cliente.
1 2 3 4 | Arquitetura de defesa mínima: [Cliente] -> [App/Portal] -> [IDP/Authn] -> [MFA via SMS?] -> [Operadora] \-> [WebAuthn / TOTP] \-> [API verif. portabilidade] |
Cenários Reais e Estudos de Caso
Estudo de caso 1 – Fintech média – takeover massivo (2025)
Contexto: fintech brasileira com 2,3M de clientes, onboarding rápido, SMS como MFA, integração frágil com operadoras. Ataque: grupo criminoso automatizou requisições de portabilidade usando dados de leaks e scripts que preenchiam portais de operadoras; alguns call centers foram contatados com documentos falsos. Resultado: 8.500 contas comprometidas, R$4,2M em prejuízo direto, MTTD inicial 18 horas. Falhas identificadas: ausência de checagem de portabilidade, logs de autenticação incompletos e falta de política de bloqueio para mudanças de número.
Aprendizados do caso 1
Decisões corretivas tomadas: (1) migração acelerada para TOTP e WebAuthn para 75% dos clientes de alto valor; (2) integração via API com operadoras para checagem de portabilidade em tempo real; (3) estabelecimento de processo de “freeze” manual para casos suspeitos; (4) revisão de SLAs com operadoras. Métrica de sucesso: redução de tentativas bem-sucedidas de takeover em 91% dentro de 90 dias.
Estudo de caso 2 – Provedor B2B – exfiltração de secretos por SMS (2026)
Contexto: provedor de serviços B2B que enviava tokens temporários por SMS para administradores. Ataque: atacante fez SIM swap do CTO e usou o acesso ao número para reset de MFA em provedores cloud, exfiltrando chaves de API. Resultado: comprometimento de ambiente de produção e perda de integridade em pipelines. Causa raiz: dependência de número do celular para recuperação de conta e ausência de roles-based access control para resets de alto risco.
Aprendizados do caso 2
Medidas adotadas: revogação de práticas de recuperação via SMS, implementação de processos de autorização dupla para reset de MFA em contas com permissões sensíveis, e segregação de segredos com HSM e rotations frequentes. Impacto: contêineres e pipelines mantidos em regime read-only até rotação dos segredos; custo operacional elevado mas necessário para restaurar confiança de clientes.
| Estudo | Vetor | Falha crítica | Controle implementado | Métrica pós-ação |
|---|---|---|---|---|
| Fintech 2025 | Portabilidade fraudulenta | SMS como MFA | WebAuthn + API verif. portab. | -91% sucesso dos ataques |
| Provedor B2B 2026 | Recuperação por número | Reset MFA sem 2a confirmação | Autorização dupla – RBAC | 0 compromissos após fix |
Ao analisar logs pós-incidente, correlacione timestamps de portabilidade ao pico de requisições de senha; esse padrão é um sinal forte de SIM swap coordenado.
Implementação Prática Step-by-Step
Checklist de preparação técnica
Título descritivo real: Inventário de dependências de MSISDN
Comando prático para inventário em sistemas Linux que armazenam telefones:
1 2 | # localizar arquivos e bancos com campos 'phone' ou 'msisdn' grep -RIl --exclude-dir=.git -E "phone|msisdn" /srv /etc /var/www || true |
Validação: confirmar resultados com amostragem de 100 entradas para verificar false positives e categorizar por sensibilidade.
Passo a passo técnico para mitigação imediata (8+ passos)
- Mapear todos os fluxos que usam MSISDN para autenticação e recuperação.
- Priorizar ativos por risco e criticidade (clientes VIP, admins, serviços financeiros).
- Desabilitar SMS como MFA para contas prioritárias; administrar rollout controlado.
- Implementar WebAuthn/TOTP e comunicar o processo de onboard aos usuários.
- Integrar com operadoras: estabelecer API para verificação de portabilidade e alertas.
- Configurar alertas no SIEM para eventos correlacionados: mudança de número, várias tentativas de OTP, picos de portabilidade por região.
- Treinar suporte e implementar scripts de verificação para call centers (KBA multi-atributo, verificação documental).
- Testar cenário de recuperação bloqueada com playbook e runbook; validar tempo de recuperação e custo operacional.
- Monitorar métricas e ajustar thresholds de detecção com feedback do SOC.
Comandos e consultas SIEM exemplares
Título descritivo real: Exemplo de regra Sigma para detectar possível SIM swap
1 2 3 4 5 6 7 8 9 10 11 | title: Possible SIM swap - rapid porting detection: selection: EventID: 4624 LogonType: 3 AuthenticationPackageName|contains: 'SMS' condition: selection and (count by SourceIPAddress > 5 within 1h) fields: - Account - SourceIPAddress - DestinationUserName |
Validação: testar com replay de logs de incidentes reais e ajustar falsos positivos com whitelists corporativas.
1 2 | Fluxo de implementação técnica: [Inventário] -> [Prioridade] -> [Desativar SMS em V1] -> [Onboard WebAuthn] -> [Integração Operadoras] -> [Regras SIEM] -> [Treinamento Suporte] |
Kit de lab
Título descritivo real: Kit de lab
Objetivo: reproduzir ataque SIM swap em ambiente controlado para treinar equipe e testar detecções. Componentes mínimos:
- Máquina Kali/Parrot com ferramentas de automação (python, requests, selenium).
- Sistema de identidade falso e banco de dados com MSISDN.
- Mock de portal de operadora que aceita requisições de portabilidade (para testes).
- SIEM local (ELK/Graylog) para ingest de logs e validação de regras.
- Ambiente de autenticação com SMS gateway simulado (ex: localstack ou SMS dev tool).
Procedimento básico: executar script que envia requisições de portabilidade no mock de operadora e verificar geração de alertas no SIEM. Métrica: detecção em menos de 30 minutos para cada teste controlado.
Executar esses labs somente em ambientes isolados e com autorização explícita. Testes contra operadoras reais sem permissão são crime e podem resultar em responsabilização penal.
Hardening, Controles e Melhores Práticas
Matriz de controles por fase do ataque
| Fase | Controle técnico | Controle processual | Indicador de eficácia |
|---|---|---|---|
| Reconhecimento | Rate limit em APIs que retornam existência de número | Política de privacidade de dados restritiva | Redução de sondagens em 80% |
| Enriquecimento | Monitoramento de credenciais vazaadas | Programa de recompensas por vazamento | Detecção precoce de exposição |
| Execução portabilidade | API de verificação com operadora | Contrato com SLA para bloqueio | Notificação em <=1 hora |
| Ativação SIM | Alertas de login de novo dispositivo com MFA exigente | Processo manual de confirmação para VIP | MTTD <4h |
| Post-compromise | Bloqueio transações sensíveis por 24h | Resposta a incidente com playbook | Redução de perdas financeiras |
Checklist de hardening técnico
- Desativar SMS como MFA para contas críticas.
- Implementar WebAuthn e suporte para autenticação sem senha.
- Integrar verificação de portabilidade com operadoras via API.
- Habilitar detecção de anomalias de localização e device fingerprint.
- Aplicar rate limiting em endpoints que retornam existência de número.
Matriz de controles por stakeholder
| Stakeholder | Responsabilidade | Controle primário | KPI |
|---|---|---|---|
| Equipe de Segurança | Detecção e resposta | Regras SIEM, playbooks | MTTD, MTTR |
| TI/Dev | Implementação técnica | WebAuthn, TOTP, logs | % de usuários migrados |
| Suporte | Verificação de identidade | Scripts de KBA, bloqueio escalado | Tempo médio de verificação |
| Jurídico/Compliance | Contratos com operadoras | SLAs, cláusulas de notificação | Tempo de resposta da operadora |
Controles técnicos sem suporte processual têm eficácia reduzida. Contratos com operadoras, treinamento de suporte e playbooks são tão críticos quanto a tecnologia.
1 2 3 4 5 6 7 8 9 | Rede/Segmentação | Identidade (RBAC/MFA/ZTNA) | Integridade de projeto e modo RUN | Validação em runtime / I/O | Observabilidade + IR OT |
Playbooks Operacionais para Blue Team e Red Team
Playbook resumido
Título descritivo real: Playbook resumido
1 2 3 4 | [ Detectar ] --> [ Contornar / Contenção ] ^ | | v [ Lições ] <------- [ Recuperar + validar ] |
Objetivo: instruir SOC e equipe de IR em ações imediatas diante de suspeita de SIM swap.
- Identificação inicial: alerta de portabilidade ou pico de OTPs não solicitadas.
- Triagem: correlacionar com logs de autenticação, IPs, geolocalização e tentativas de reset.
- Isolamento: bloquear alterações críticas de autenticação e criar freeze na conta.
- Verificação operacional: contatar operadora via canal técnico e solicitar confirmação de portabilidade.
- Comunicação interna: notificar equipe de fraude, jurídico e liderança de produto.
- Análise forense: coletar logs, capturar snapshots e preservar evidências.
- Remediação: reverter alterações feitas pelo atacante, rotacionar credenciais, forçar reauth com métodos fortes.
- Recuperação: acompanhar restauração de acesso com cliente e monitorar por 30 dias.
- Revisão pós-incidente: lições aprendidas, atualização de playbook e treinamento.
Blue Team – checklist operacional
- Ativar regras de correlação específicas para SMS/portabilidade.
- Configurar alertas de aumento súbito de solicitações de OTP.
- Habilitar bloqueio automático de alterações de número para contas sensíveis.
- Tornar obrigatório WebAuthn para adm e contas de alto risco.
- Validar contratos com operadoras para canais de emergência.
Red Team – checklist para simular ataque
- Obter autorização por escrito e escopo claro da simulação.
- Usar data fabrication e mock services para testes de engenharia social.
- Executar testes de portabilidade no ambiente de laboratório, não em operadoras reais.
- Testar scripts de automação contra API mock de operadora.
- Validar detecção do SOC e tempo de resposta real com playbook.
Métricas, KPIs e Auditoria Técnica
Principais métricas a monitorar
Defina KPIs mensuráveis para avaliar eficácia de controles. Métricas críticas:
1 2 3 4 | [ Coleta ] -> [ Indicador ] -> [ Limiar/alerta ] ^ | | v [ Melhoria ] <-------------- [ Ação / ticket ] |
- MTTD – tempo médio para detectar SIM swap ou portabilidade fraudulenta.
- MTTR – tempo médio para mitigar e recuperar conta após detecção.
- Taxa de sucesso do ataque – % de tentativas que resultaram em takeover.
- % de contas de alto risco com autenticação sem SMS.
- Tempo de notificação da operadora após solicitação de verificação.
Métricas operacionais e SLAs
Recomenda-se SLAs internos: detecção inicial em <2 horas para contas sensíveis e resposta em <4 horas. Com operadoras, buscar acordos para notificação em <1 hora para solicitações de portabilidade que afetam clientes corporativos.
| Métrica | Objetivo | Método de medição |
|---|---|---|
| MTTD | <4 horas | Correla logs SIEM e alertas de portabilidade |
| MTTR | <24 horas | Tempo desde isolamento até recuperação completa |
| % migração MFA | >90% contas sensíveis | Inventário IDP |
Auditoria técnica – checklist
Título descritivo real: Checklist de auditoria
| Item | Verificação | Indicador |
|---|---|---|
| Logs de autenticação | Retenção >= 90 dias, completos | OK/Não OK |
| Integração com operadora | API disponível e testada | OK/Não OK |
| Política de recuperação | Documentada e testada | OK/Não OK |
| Controle de MFA | SMS desativado para contas críticas | Percentual migrado |
Erros Comuns, Armadilhas e Correções
Erros comuns na arquitetura e operação
1) Dependência excessiva de SMS. 2) Falta de contratos com operadoras que definam tempo de notificação. 3) Suporte sem scripts rígidos permitindo engenharia social. 4) Log insuficiente para correlação de eventos. Essas falhas aumentam probabilidades de sucesso do atacante e dificultam a resposta.
1 2 3 4 | [ Anti-padrão ] --> [ Sintoma ] --> [ Correção ] | v [ Evidência / regressão ] |
Armadilhas jurídicas e de conformidade
Pressões por recuperação rápida podem levar equipes a relaxar verificações, criando responsabilidade legal. Correção: padronizar níveis de acesso e exigir aprovação formal para resets em contas com permissões elevadas; documentar decisões com trilhas de auditoria.
Não confunda velocidade com eficácia: restaurar acesso rápido sem investigação pode permitir que o atacante retenha backdoors.
Correções práticas e trade-offs
Exigir mais verificações aumenta fricção e pode impactar churn. Trade-off gerenciável: aplicar controles por segmentação de risco; contas de alto risco recebem verificações rígidas, contas de baixo risco têm caminhos menos restritivos.
FAQ Técnico para Busca Orgânica
O que é SIM swap e como afeta empresas?
SIM swap é a transferência do número de telefone para outro SIM controlado pelo atacante; afeta empresas quando esse número é fator de autenticação ou recuperação, permitindo account takeover e transações fraudulentas.
Como detectar um SIM swap rapidamente?
Detecte portabilidade ou ativação de SIM por meio de integração com operadoras ou sinais indiretos: picos de OTPs, logins de novos dispositivos, mudanças de localização geográfica inconsistentes e solicitações de recuperação em massa.
O SMS como fator de autenticação é proibido?
Não é proibido, mas é considerado fraco. Recomendação: migrar para TOTP ou WebAuthn. Se manter SMS, adotar controles compensatórios como verificação de portabilidade e bloqueio temporário de transações sensíveis após mudanças de número.
Quais integrações técnicas são necessárias com operadoras?
APIs para verificação de portabilidade, canais de notificação de eventos, e acordos para verificação manual em casos suspeitos. Técnicos precisam negociar endpoints seguros, autenticação mTLS e SLAs de resposta.
Padronizar scripts, usar KBA com múltiplos fatores, exigir autorização de segundo nível para alterações de número e registrar chamadas com trilha de auditoria. Treinamento prático com simulações de ataque é essencial.
Quais logs são essenciais para investigação?
Logs de autenticação, histórico de MFA, eventos de portabilidade/integração com operadora, logs de suporte e tickets de recuperação, registros de IPs e device fingerprinting. Retenção mínima sugerida: 90 dias para investigação completa.
Como priorizar contas para mitigação?
Priorize por exposição financeira, privilégios administrativos e criticidade do serviço. Faça segmentação automática no IDP para aplicar políticas diferentes por categoria.
Quais são as métricas que indicam redução de risco?
MTTD, MTTR, redução percentual de takeovers bem-sucedidos, % de contas com autenticação forte e tempo de notificação de operadora.
O que um Red Team pode testar sem violar leis?
Testes internos com mock de operadora, simulação de engenharia social com dados fictícios, validação do SOC contra cenários replicáveis em laboratório. Evite qualquer interação com operadoras reais sem contrato e autorização.
Como lidar com clientes afetados e comunicação pública?
Ter roteiro de comunicação transparente, oferecer monitoramento gratuito e cobertura de perdas quando aplicável, coletar evidências e coordenar com órgãos reguladores. Comunicação rápida e honesta reduz danos reputacionais.
Considerações Finais
SIM swap não é apenas uma fraude técnica; é um problema sociotécnico que exige contrato, tecnologia, processo e mudança cultural. Empresas que tratam a autenticação por SMS como solução final estão aumentando risco sistemático. A defesa eficaz combina migração para autenticação forte, integração direta com operadoras, aprimoramento de políticas de suporte e estratégias de detecção proativa. No final, segurança é economia de risco: quanto você aceita pagar em fricção para reduzir a probabilidade de grandes perdas?
Próximo passo: execute este checklist inicial em 30 dias: (1) mapear dependências de MSISDN; (2) identificar 20% de contas com maior risco; (3) desativar SMS para esse grupo; (4) integrar verificação de portabilidade com operadora; (5) rodar um exercício de mesa com SOC e suporte.
Recursos Visuais Sugeridos
Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.
- MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
- CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
- NIST Cybersecurity Framework – figuras oficiais e referências de controles.
- ENISA – relatórios anuais com gráficos e mapas de ameaça.
- Kali Linux – documentação oficial com fluxos práticos.
- Parrot Security – documentação oficial com arquitetura modular.
Referências
- “Alerta sobre fraudes via portabilidade e SIM swap”, CERT.br, 2026, https://www.cert.br/alerts/sim-swap-2026
- “Boas práticas de autenticação e recomendações NIST SP 800-63”, NIST, 2024, https://pages.nist.gov/800-63-3/
- “Relatório anual de fraude móvel 2026”, Mobile Ecosystem Forum – MEF, 2026, https://www.mef.net/research/2026-mobile-fraud-report
- “Diretrizes sobre segurança de provedores de telecom”, ANATEL, 2025, https://www.anatel.gov.br/seguranca-telecom
- “Threat Advisory: SIM swap trends”, CISA, 2026, https://www.cisa.gov/sim-swap-advisory-2026
- “SMS OTP now a top vector in account takeover”, Microsoft Security, 2025, https://www.microsoft.com/security/blog/sim-swap-account-takeover-2025
- “SIM swap and port-out fraud: mitigation strategies”, Kaspersky Threat Research, 2026, https://www.kaspersky.com/blog/sim-swap-mitigation-2026
- “Best practices for WebAuthn adoption”, FIDO Alliance, 2025, https://fidoalliance.org/implementation/webauthn-best-practices
- “Signal analysis for SS7 and Diameter anomalies”, GSMA Intelligence, 2025, https://www.gsma.com/security/signal-analysis-ss7-diameter
- “Operational playbooks for incident response – SIM swap scenarios”, SANS Institute, 2025, https://www.sans.org/white-papers/sim-swap-incident-response
- “Telecom fraud and regulation: Brazilian perspective”, Fundação Getulio Vargas – FGV, 2026, https://www.fgv.br/telecom-fraud-2026
- “Portabilidade numérica: riscos e controles”, ANATEL technical bulletin, 2025, https://www.anatel.gov.br/portabilidade-tecnica-2025
- “Blue Team detection engineering for authentication attacks”, Elastic Security, 2025, https://www.elastic.co/security/sim-swap-detection
- “Red Team methods for social engineering without harm”, OWASP, 2024, https://owasp.org/www-project-social-engineering
