Golpe do falso gerente é daquele tipo de fraude que cresce porque depende do fator humano: alguém atende, confia, “valida” e perde dinheiro. O insight aqui é que Google e Itaú estão tentando virar o jogo antes do primeiro “alô” — usando recursos de segurança do Android para bloquear chamadas fraudulentas ainda na chegada. Segundo o Eurisko.com.br, a parceria mira principalmente a técnica de call spoofing, quando o criminoso consegue mascarar a origem da ligação com um número “bonito” e plausível.
Por que o “falso gerente” ainda funciona (e por que isso importa pra devs)
Na minha experiência, golpes via ligação ganham porque a conversa é um pipeline de decisão humano. Primeiro você atende. Depois você tenta verificar. Em seguida você segue instruções — geralmente com urgência (“é suspeito”, “precisa agora”, “não posso formalizar por mensagem”). A tecnologia bancária sempre tentou reagir com scripts e orientações. Só que o atacante ajusta a mensagem para contornar o que é “suspeito”.
O ponto técnico do problema é que o sistema não está interrompendo o canal no início. Ele só começa a “entender” quando a vítima já entrou na conversa. Quando você depende de detecção durante o diálogo, você inevitavelmente precisa confiar no que foi dito. E isso é atrasado.
Segundo o Eurisko.com.br, o avanço agora é deslocar a defesa para o momento anterior: impedir que a chamada chegue ao usuário, reduzindo drasticamente a superfície de ataque. Em termos práticos, é como colocar um WAF antes do backend: você não tenta consertar a requisição depois que ela já atravessou a borda.
Como o Android entra nisso: bloqueio antes do “alô”
O que chama atenção (e eu considero estrategicamente correto) é usar recursos de segurança do Android para filtrar chamadas com base em inteligência de fraude e sinais do contexto. Ainda conforme o Eurisko.com.br, a iniciativa começou a ser disponibilizada para celulares com Android 11 ou mais recentes e exige que pelo menos um aplicativo oficial do Itaú esteja instalado no aparelho.
O porquê dessa exigência de app instalado
Do ponto de vista de engenharia, isso faz sentido. “Qual app está no dispositivo” vira um sinal de contexto. Se o usuário não tem relação com o ecossistema do banco, a probabilidade de a chamada ter valor fraudulento específico (para aquele banco) aumenta, e o alvo muda. Com o app oficial instalado, o sistema consegue acionar fluxos e políticas mais precisas, com melhor taxa de acerto.
Também reduz custo computacional e risco de falsos positivos: você só aplica a proteção quando há chance real do usuário estar no fluxo de relacionamento bancário.
Call spoofing: o truque por trás do número “legítimo”
O Eurisko.com.br cita a técnica conhecida internacionalmente como call spoofing. Em termos simples: o criminoso faz o celular exibir um número que parece real. Quando isso acontece, o usuário confia no “identificador”. O ataque não é só social — ele mexe com signal integrity na camada de apresentação.
Quando a defesa é só baseada em “o número é estranho”, você perde. O número pode não estar estranho. Por isso a mudança para bloqueio proativo antes do toque é um salto.
O que torna essa abordagem melhor do que “deixar o usuário decidir”
Eu sempre digo para equipes: quando você deixa o usuário decidir, você está transferindo o problema para o ponto mais caro (atenção humana). A abordagem Google + Itaú muda o trade-off:
- Menos atrito para o bom usuário: ele nem ouve a ligação.
- Mais controle antes do ataque: o bloqueio acontece cedo.
- Menos dependência de scripts: não precisa convencer o usuário durante a conversa.
Na prática, isso tende a reduzir tanto perdas quanto “tempo mental” do usuário. E tem um efeito colateral bom: diminui o impacto emocional (“por que fui enganado?”), porque ele nem chegou a cair na etapa de validação.
Comparações reais: outras formas de mitigar fraude e onde elas falham
Vale comparar com estratégias comuns que eu vejo em sistemas e projetos de fraude:
- Bloqueio por lista negra de números: fácil de implementar, mas o atacante migra rápido (novos números, variações).
- Detecção durante a conversa (ASR/NLP): melhor que lista, mas ainda é tarde — e exige qualidade de voz, idioma, ruído.
- Interação via app (chamadas internas): reduz golpes externos, mas não elimina o canal telefônico e pode confundir usuários.
- Autenticação forte fora do canal (ex.: só libera ações no app): ajuda bastante, mas não evita o vazamento inicial (ex.: engenharia social para instalar malware, abrir sessão, etc.).
O diferencial do caso descrito pelo Eurisko.com.br é atacar o momento de contato, não só o resultado da ação. Isso geralmente é onde os golpes nascem.
Implicações práticas para quem programa: segurança “na borda” e sinais
Se você desenvolve produto web/app, tem duas lições diretas aqui.
1) Proteja o canal antes do evento principal
Em web, é parecido com: firewall, rate limiting, bot detection antes do endpoint sensível. Se você espera o usuário “começar a interagir” para só então detectar fraude, você perde tempo e aumenta risco.
2) Contexto vale mais do que regra fixa
A exigência de Android 11+ e app Itaú instalado indica que a decisão de segurança usa contexto. Em sistemas modernos, isso é o caminho: sinais (estado do dispositivo, presença de app, histórico, padrões) são melhores do que heurísticas rígidas.
Uma armadilha que eu vejo devs cometerem
É tratar “bloqueio” como uma regra binária. Em produção, você precisa calibrar a política para evitar falsos positivos. Sempre que implemento um sistema de bloqueio automático, eu defino 3 níveis: permitir, revisar, bloquear. E só aumento o bloqueio após medir impacto no usuário legítimo.
Na Prática: como você replicaria o “bloqueio antes do evento” no seu produto
Vou dar um exemplo de arquitetura que funciona bem em web/mobile quando você quer bloquear tentativa de fraude antes do usuário executar a ação principal.
- Defina o evento sensível: por exemplo, “transferir dinheiro”, “alterar dados cadastrais” ou “solicitar empréstimo”.
- Interponha uma camada de decisão: um serviço que avalia risco antes de liberar a transação.
- Use sinais do contexto: dispositivo, app version, IP/ASN, device integrity, velocidade de tentativas, reputação.
- Crie estados de política: ALLOW, CHALLENGE, BLOCK.
- Meça falsos positivos e prepare um caminho de contestação
Em código, um padrão simples (pseudo-realista) para separar políticas:
function decideRisk({ deviceOk, hasOtpRecently, ipReputation, velocity24h, callerClaimsMismatch }) {
// 1) Bloqueio duro: sinais muito fortes
if (callerClaimsMismatch && !deviceOk) return { policy: "BLOCK", reason: "inconsistency_device" };
// 2) Desafio: suspeito, mas não certeza
if (!ipReputation || velocity24h > 5 || !hasOtpRecently) {
return { policy: "CHALLENGE", reason: "risk_suspected" };
}
// 3) Permitir: baixo risco
return { policy: "ALLOW", reason: "looks_normal" };
}
// Exemplo de uso:
const decision = decideRisk({
deviceOk: true,
hasOtpRecently: false,
ipReputation: true,
velocity24h: 1,
callerClaimsMismatch: false
});
if (decision.policy === "BLOCK") {
// retorne erro genérico e registre para auditoria
throw new Error("Operação indisponível no momento.");
}
if (decision.policy === "CHALLENGE") {
// exija OTP, step-up auth ou validação adicional
// (o objetivo é interromper a fraude antes do commit)
return { next: "require_step_up_auth" };
}
return { next: "proceed" };O “porquê” aqui é o mesmo do caso Google + Itaú: você não quer que o fraudador chegue ao ponto de realizar a ação. Quer interromper cedo. Mesmo que a decisão não seja perfeita, o impacto diminui porque você reduz a janela de ataque.
Erros Comuns (e o que evitar) quando você implementa mitigação parecida
Eu já vi vários times tentarem “fazer algo parecido” e tropeçarem. Os erros mais frequentes:
- Bloquear 100% sem calibração: aumenta suporte, irrita usuários e pode ser contornado.
- Usar apenas um sinal (ex.: só lista negra): fraude evolui e você fica sempre atrás.
- Não registrar motivos: sem observabilidade, você não melhora o modelo nem as regras.
- Ficar sem caminho de contestação: se bloquear usuário legítimo, você precisa de recuperação.
- Tratar “confiar no número” como segurança: no caso do call spoofing, isso é literalmente a falha do atacante.
Uma nuance: quanto mais cedo você bloqueia, mais importante fica ter telemetria para entender por que bloqueou. Sem isso, você corre o risco de “otimizar contra métricas erradas”.
FAQ
O bloqueio funciona em qualquer Android?
Segundo o Eurisko.com.br, a disponibilização começou em dispositivos com Android 11 ou versões mais recentes. Em versões anteriores, a proteção pode não estar disponível da mesma forma.
Precisa ter o app do Itaú instalado?
Sim. A iniciativa, conforme descrito pelo Eurisko.com.br, funciona quando um aplicativo oficial do Itaú está instalado no aparelho. Isso melhora o contexto e a precisão da proteção.
Como isso reduz o “call spoofing”?
Em vez de confiar apenas no número exibido, o sistema usa recursos de segurança e sinais para interromper a chamada antes de chegar ao usuário — reduzindo a eficácia do mascaramento da origem.
Isso elimina todos os golpes?
Não. É uma camada forte no canal de ligação, mas fraude pode ocorrer por outros vetores (mensagens, e-mail, links, engenharia social). A defesa precisa ser em camadas.
O que eu, como dev, posso tirar disso para meu sistema?
Proteja o “evento sensível” com decisão precoce e context-based policies (ALLOW/CHALLENGE/BLOCK). E meça falsos positivos com observabilidade para ajustar continuamente.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.