Fraude bancária: mecanismos, sinais e antifraude
Como funcionam os principais vetores (engenharia social, SIM swap, malware bancário, ATO) e quais sinais os sistemas antifraude monitoram para barrar.
🎧 audiobook · nível 1
Fraude bancária: mecanismos, sinais e antifraude
Conteúdo defensivo
Este artigo descreve como fraudes acontecem para que times de risco, engenharia e usuários consigam reconhecer e mitigar. Não há instruções operacionais para cometer fraude.
Vetores mais comuns
- Engenharia social por telefone (falso atendente, falso gerente).
- SIM swap — atacante porta o número da vítima e captura SMS de OTP.
- Malware bancário (Android RATs como Brata, Cerberus) com overlay e accessibility abuse.
- Account Takeover via credenciais vazadas + credential stuffing.
- Fraude de boleto / Pix copia-e-cola com clipboard hijacking.
- Engenharia reversa de apps mal protegidos para extrair tokens.
Sinais que sistemas antifraude observam
- Device fingerprint novo + transação alta + horário atípico.
- Velocity: várias transações pequenas em janela curta.
- Geo impossível (login BR e Pix de IP europeu em 2 min).
- Mudança recente de credenciais ou de chave Pix antes de transação.
- Comportamento de digitação (cadência, swipe) anômalo — behavioral biometrics.
- Reuso de device em múltiplas contas (mule farms).
Camadas de defesa no app
- Root/jailbreak detection + Play Integrity / DeviceCheck.
- Bloqueio de overlay e de Accessibility services não autorizados.
- Pinning de certificado e ofuscação de strings sensíveis.
- Limites dinâmicos: contato novo, valor alto → step-up auth biométrico.
- Cooling period após troca de senha/dispositivo (24-48h sem transferências altas).
Modelagem de risco em produção
A maioria dos bancos usa ensembles (gradient boosting + redes profundas) sobre features de device, sessão, histórico e grafo (quem se relaciona com quem via PIX). O modelo não bloqueia sozinho — gera score, e regras de negócio decidem aprovar, desafiar (3DS, biometria, ligação) ou recusar.
Referências
Template OffSec · aplicar antes de rodar
Objetivo → Preparação → Execução → Evidência → Ética
Objetivo
Entender o ciclo de fraude (device, comportamento, pagamento) para reduzir falso-positivo do lado defensivo, sem operar do lado ofensivo em produção.
Pré-requisitos
- Ambiente de sandbox de PSP (Stripe/Adyen/PagSeguro test mode)
- Cartões de teste oficiais do PSP
- Log de comportamento (mouse, touch, dwell) coletado em ambiente controlado
Passos
- Modele o perfil legítimo (baseline de device, horário, ticket médio)
- Injete transações-teste variando um atributo por vez
- Meça o score do antifraude e onde a decisão muda
- Documente feature-importance sem expor a lógica proprietária ao público
- Feche o loop: cada regra criada tem plano de revisão trimestral
Evidências a coletar
- Planilha com transações-teste × score × decisão
- Trilha de decisão do motor (rule fired, score final)
- Chargebacks históricos correlacionados
Regra prática: se você não guardou evidência reprodutível, o achado não existe.
Guia prático (lab autorizado)
alvo · Ambiente sandbox do próprio PSP com cartões oficiais de teste
curl -X POST https://api.stripe.com/v1/payment_intents ... -d 'amount=100' -d 'payment_method=pm_card_visa' # test mode keyverificar · Cruze o resultado do antifraude com o log bruto do gateway. Divergência = investigar antes de virar regra.
Checklist interativo
Checklist ético (marcar antes do primeiro comando)
Autorização, escopo, lab e proteção de dados. Sem 100%, não roda fora do lab.
Prática segura · Fraude & Antifraude
→ guia do labMonte um ambiente isolado antes de qualquer teste — use Docker (DVWA/juice-shop), uma VM host-only ou um alvo autorizado (HTB, TryHackMe, PortSwigger Academy).
Nunca aponte para alvo em produção. Se estiver no celular, use proot-distro + Debian para não sujar o Termux principal.