Verificação de Identidade Real e Mitigação de Números Virtuais
Verificação de Identidade Real e Mitigação de Números Virtuais
Planejamento técnico-jurídico para redução de fraude de identidade em WhatsApp, Telegram e grupos de Facebook — com cruzamento regulatório Anatel/ABR Telecom e metodologia de varredura de dados vazados.
00 Premissa
Nenhuma das medidas abaixo é implementável unilateralmente por terceiros — WhatsApp e Telegram são plataformas fechadas, controladas pela Meta e pela Telegram FZ-LLC, e o Facebook Groups é controlado pela Meta. O plano se divide em três frentes de execução real:
| Frente | O que é possível | Quem executa |
|---|---|---|
| A — Proposta técnica/regulatória | Documento técnico-jurídico para lobby, petição ou fundamentação de ação judicial (Marco Civil, art. 19–22) | Consultoria redige; plataforma ou Judiciário decide |
| B — Governança de comunidades próprias | Regras de admissão e moderação em grupos administrados (WhatsApp, Telegram, Facebook) | Executável 100% de imediato |
| C — Triagem OSINT/CTI | Detecção de indícios de número virtual ou perfil falso, sem depender da plataforma | Metodologia Maltego / holehe / Sherlock-Maigret |
01 WhatsApp & Telegram — mitigação de números virtuais
A verificação hoje é essencialmente heurística/reputacional, não determinística. Isso abre espaço para números de gateway VoIP (SMS-Activate, TextNow, eSIM descartável) serem verificados via chamada de voz, canal historicamente mais permissivo que o SMS.
Diagnóstico técnico
- Verificação automática de operadora só ocorre quando linha e aparelho são vendidos juntos ou via eSIM legítimo homologado.
- Fora isso, tudo passa por SMS/chamada — canal que qualquer gateway VoIP consegue receber.
- A recusa de número VoIP não é regra fixa: é sinal de risco, não bloqueio garantido.
Frente A — proposta de política à plataforma
| Medida proposta | Mitigação | Observação |
|---|---|---|
| Consulta em tempo real ao HLR da operadora (classifica mobile/landline/voip) | Bloqueia na origem gateways não homologados | Já existe comercialmente (ex. Twilio Lookup) |
| Cruzamento obrigatório com a BDR da ABR Telecom antes do cadastro no Brasil | Número inexistente na base nacional = forte indício de linha não brasileira/virtual | Depende de acordo Meta–ABR Telecom |
| Selo "conta com número não verificado por operadora" | Transparência ao destinatário sem necessidade de banimento | Baixo custo de implementação |
| Reforço de detecção comportamental pós-registro | Ataca o sintoma quando a origem não foi barrada | Parcialmente já existente |
| Biometria/selfie para contas de alto volume comercial | Extensão do que já se exige na API Business a contas pessoais com padrão de bot | Exige base legal LGPD específica |
Frente B — governança de grupos administrados (aplicável hoje)
- Nunca aceitar automaticamente número sem foto de perfil + conta recém-criada.
- Checar o número na BDR da ABR Telecom (consultanumero.abrtelecom.com.br) antes de validar como contato legítimo.
- Cruzar com Lookup técnico (Twilio Lookup, Numverify) — combinação "não localizado" + "voip" é evidência robusta.
- Exigir DDD compatível com a região declarada pelo usuário.
- Cruzar reputação do número via holehe/Maigret — número que só existe no WhatsApp e em nenhuma outra plataforma é sinal de linha criada só para aquele uso.
Enquanto a Meta não muda a arquitetura de verificação, nenhuma medida do lado do usuário/admin é 100% eficaz — o máximo alcançável é elevar o custo/atrito de quem usa número virtual, não eliminar a possibilidade. A Frente A é o único caminho estrutural.
Telegram — grupos/canais administrados
- Captcha de entrada via bot anti-spam (ex.: SafeGuard Bot).
- Exigir @username público, não apenas número — reduz anonimato total.
- Expulsão automática de contas sem foto, sem bio e criadas recentemente.
- Ativar "Restrict Saving Content" para reduzir circulação de material sensível.
02 Facebook Groups — remoção de apelidos
A função de apelido específico por grupo ("Group nickname") quebra a rastreabilidade entre autor de uma postagem e o perfil real — ponto crítico em casos de difamação em massa como os documentados pela RDS em grupos de grande alcance.
Proposta técnica (Frente A)
- Desativação da função de apelido em grupos públicos e em grupos com mais de N membros, mantendo apenas o nome de perfil vinculado à conta principal.
- Exibição obrigatória do nome de perfil real ao lado do apelido, quando este for mantido.
- Log de auditoria retido pela Meta vinculando post → apelido → conta real → IP/dispositivo, exigível via ordem judicial (Marco Civil, art. 22).
Governança de grupos administrados (Frente B)
- Desativar "permitir apelidos no grupo" em Configurações do Grupo → Nomes de Membros.
- Perguntas de admissão com verificação cruzada.
- Moderação ativa: post com apelido sem nome real visível → remoção.
03 Cruzamento com Anatel / ABR Telecom
A Anatel não guarda nome/CPF do titular da linha — isso está na base interna da operadora. A Anatel regula o setor; a ABR Telecom (Resolução Anatel 73/1998) administra a Base de Dados Nacional de Referência (BDR) de portabilidade.
| Dado | Onde está | Acesso |
|---|---|---|
| Operadora atual do número | BDR — ABR Telecom | Público, gratuito |
| Histórico de portabilidade | BDR — ABR Telecom | Público |
| Tipo de linha (fixa/móvel) | BDR — ABR Telecom | Público |
| Nome/CPF do titular | Base interna da operadora | Restrito — ordem judicial |
| Geolocalização de linha (ERB) | Operadora | Restrito — ordem judicial |
Consulta pública oficial
Ferramenta em consultanumero.abrtelecom.com.br: informa-se número + DDD, resolve captcha, e o retorno mostra prestadora atual e status de portabilidade.
- Prestadora = MVNO de venda 100% digital sem loja física → reforça hipótese de linha descartável.
- Portabilidade recente para operadora pré-paga digital pouco antes do incidente investigado → padrão típico de linha criada para o golpe.
- Retorno "não encontrado na base" → forte indício de número virtual/gateway SMS não homologado no Brasil.
- Cruzado com Lookup técnico (mobile/landline/voip): "não existe" + "voip" fecha o padrão como evidência técnica robusta.
Cadastro pré-pago — o que já é regulatório (Resolução Anatel 477/2007, art. 58)
A atualização de cadastro via aplicativo/portal da operadora já é uma obrigação regulatória, não uma proposta nova: nome completo, endereço, CPF/CNPJ e data de nascimento são exigidos desde a ativação do chip, com bloqueio em caso de não validação. Na fase mais avançada do projeto, a validação passa a ocorrer por identificação digital (biometria/documento).
Existe até um portal centralizado entre operadoras — cadastropre.com.br — para o próprio titular consultar linhas pré-pagas ativas em seu CPF (uso restrito ao próprio CPF do consulente; não serve para consulta de terceiros sem ordem judicial).
| Medida | Status regulatório real |
|---|---|
| Cadastro/atualização via app da operadora | ✅ Já exigido — Resolução Anatel 477/2007, art. 58 |
| Validação por CPF na ativação | ✅ Já exigido — Lei 10.703/2003 |
| Validação por identificação digital/biometria | ⚠️ Prevista na fase 3, aplicação ainda parcial |
| Bloqueio automático por cadastro não confirmado | ✅ Já ocorre |
| Fiscalização ativa de CPFs duplicados/inválidos | ❌ Reconhecidamente falha — principal brecha |
04 Verificação de identidade em aplicativo próprio
Arquitetura de camadas para produto próprio (ex.: canal de denúncias, comunidade OSINT Brasil) que exija verificação robusta na entrada.
- Verificação de número real: SMS + fallback de chamada + checagem de operadora (line type lookup).
- Geolocalização obrigatória no primeiro acesso: GPS + IP geolocation cruzados, detectando divergência típica de VPN/proxy.
- Liveness detection facial: selfie com prova de vida comparada a documento oficial.
- Validação documental: OCR de RG/CNH + consulta à base de CPF.
- Device fingerprinting: IMEI, modelo, SO — detecta múltiplas contas no mesmo aparelho.
- Análise comportamental pós-cadastro: velocidade de digitação, horários, padrão de uso.
- Reputação cruzada (SOCMINT): checagem se número/e-mail já existe em outras plataformas.
Geolocalização e biometria são dado sensível (LGPD art. 5º, II). Exigem: base legal específica com consentimento destacado, finalidade determinada (art. 6º, I), Relatório de Impacto à Proteção de Dados (RIPD) prévio, prazo de retenção definido e DPO nomeado. Sem isso, o próprio mecanismo de segurança vira passivo jurídico perante a ANPD.
05 Canal oficial de comunicação para advogados
O golpe do "advogado clonado" — perfil falso copiando nome e foto para solicitar depósitos de clientes — é hoje um dos vetores de fraude mais recorrentes em WhatsApp no Brasil. A mitigação estrutural passa pela verificação oficial da Meta.
| Camada | O que resolve | Como funciona |
|---|---|---|
| WhatsApp Business API + Meta Business Manager verificado (Selo Verde) | Nome da empresa exibido mesmo sem o contato salvo pelo cliente | Exige API oficial (não o app comum), Business Manager verificado com documentos legais, CNPJ ativo |
| Meta Verified (Selo Azul) | Confirma autenticidade da conta ao lado do nome | Via API oficial + provedor parceiro (BSP); assinatura mensal |
Recomendação prática para escritório
- Registrar o número exclusivamente como WhatsApp Business vinculado ao CNPJ do escritório — nunca conta pessoal.
- Verificar o Meta Business Manager com CNPJ + comprovante de endereço.
- Buscar o Selo Verde via um BSP homologado pela Meta.
- Publicar cláusula de verificação no site, redes sociais e contrato de honorários informando o canal oficial único.
- Nunca aceitar solicitação de depósito/PIX por WhatsApp sem confirmação em canal secundário.
06 Vazamento de banco de dados de clientes — vetores e varredura
Vetores mais comuns
| Vetor | Como acontece |
|---|---|
| Phishing/engenharia social | Colaborador clica em link malicioso; credencial é roubada |
| Infostealers | Malware captura credenciais salvas; dados viram "stealer logs" vendidos em fóruns |
| Configuração incorreta de nuvem | Bucket S3 ou banco exposto sem autenticação na internet |
| Vazamento por terceiro | CRM/ERP/SaaS terceirizado comprometido, expondo a base de todos os clientes dele |
| Insider threat | Ex-colaborador leva a base ao sair |
| Credential stuffing | Senha vazada em outro serviço reutilizada no sistema do escritório |
| SQL Injection | Falha em sistema de peticionamento ou site institucional não corrigido |
Metodologia de varredura (CTI/OSINT)
- Escopo: domínio institucional, e-mails corporativos, CPF/CNPJ dos sócios.
- Bases de vazamento consolidadas: Have I Been Pwned (API), DeHashed, IntelligenceX, LeakCheck.
- Monitoramento de fóruns/canais ativos: fóruns de cibercrime, canais de Telegram especializados, Pastebin/Ghostbin.
- Google Dorking: operadores site:, filetype:, intitle:index.of combinados ao domínio-alvo.
- Infraestrutura exposta: Shodan/Censys para bancos, buckets ou painéis administrativos públicos sem autenticação.
- Correlação: cruzamento dos achados com o quadro societário/colaboradores via grafo Maltego/NetworkX.
- Relatório e resposta: classificação por severidade, notificação de titulares (LGPD art. 48) quando aplicável, evidência para responsabilização de terceiro quando for o caso.
07 Resumo executivo
| Etapa | Ação | Prazo sugerido |
|---|---|---|
| 1 | Mapear grupos administrados e aplicar Frente B imediatamente | 1–2 semanas |
| 2 | Redigir documento técnico de proposta (Frente A) para petições Marco Civil em andamento | 2–4 semanas |
| 3 | Desenhar arquitetura de verificação + RIPD para app próprio, se aplicável | Conforme roadmap |
| 4 | Integrar triagem OSINT (holehe/Maigret/Sherlock) como evidência de conta virtual nos dossiês | Contínuo |
| 5 | Migrar canais de atendimento jurídico para WhatsApp Business verificado | 2–3 semanas |
| 6 | Implantar rotina periódica de varredura de vazamento (HIBP + Dorking + Shodan) | Mensal |
Comentários
Postar um comentário