Prevenção de account takeover (ATO) e fraude em fintechs

Como o account takeover acontece em fintechs

Account takeover (ATO) é o comprometimento de uma conta legítima por um terceiro, que passa a operar como se fosse o titular. Em fintechs, o impacto é direto: transferências Pix não autorizadas, abertura de crédito fraudulento, mudança de dados de contato para silenciar alertas e cash-out via contas-laranja. Diferentemente de uma invasão de infraestrutura, o ATO frequentemente não dispara controles tradicionais porque usa credenciais válidas e fluxos legítimos da aplicação.

Os vetores predominantes são quatro. O credential stuffing reutiliza pares de e-mail e senha vazados em outros serviços, testados em massa contra a tela de login com automação (listado pelo OWASP como OAT-008, Credential Stuffing, no Automated Threat Handbook). O SIM swap transfere a linha telefônica da vítima para um chip controlado pelo atacante, neutralizando qualquer segundo fator entregue por SMS ou chamada. A engenharia social, incluindo golpes de falso funcionário e phishing de OTP em tempo real, induz a própria vítima a entregar códigos ou aprovar push notifications.

O quarto vetor é o phishing de credenciais com proxy reverso (kits como Evilginx), que intercepta usuário, senha e token MFA na mesma sessão, contornando MFA baseado em OTP. É justamente esse cenário que a NIST 800-63B classifica como ataque de canal e que apenas autenticadores ligados criptograficamente à origem (phishing-resistant) conseguem bloquear.

O ponto central para CTOs e times de risco: esses vetores se combinam. Uma campanha real começa com listas de credenciais vazadas, escala com automação, escapa do MFA fraco via SIM swap ou proxy reverso e termina com engenharia social para aprovar a transação final. Defender uma camada isolada apenas desloca o atacante para a próxima.

Sinais de ATO: o que monitorar antes do prejuízo

O ATO deixa rastros mensuráveis antes do cash-out, e detectá-los cedo é o que separa um incidente contido de uma perda materializada. Os sinais úteis raramente são uma única regra binária; são desvios do comportamento histórico de cada conta e do conjunto de contas.

Na camada de autenticação, observe picos de tentativas de login com baixa taxa de sucesso (assinatura de credential stuffing), logins bem-sucedidos a partir de ASNs de datacenter ou redes de proxy residencial, viagens impossíveis (login no Brasil e minutos depois em outro país) e velocidade anômala de tentativas por IP, por conta e por device. O OWASP recomenda tratar essas métricas de forma agregada, não apenas por IP, já que botnets distribuem a carga.

Na camada de conta e transação, os sinais de pós-comprometimento são igualmente reveladores: troca de e-mail, telefone ou senha seguida de tentativa de transferência; cadastro de novo dispositivo e Pix de alto valor para chave nunca usada na mesma sessão; desativação de notificações; e mudança de padrão de horário ou de beneficiários. Correlacionar o evento de mudança de credencial de contato com a transação subsequente é um dos detectores de fraude mais eficazes em fintechs.

Transformar esses sinais em ação exige telemetria centralizada e correlação contínua. Logs de autenticação, device fingerprint, geolocalização e eventos transacionais precisam convergir para um mesmo pipeline de detecção, onde regras determinísticas e modelos de anomalia atribuem risco em tempo quase real. Sem essa consolidação, cada sinal isolado vira ruído.

MFA resistente a phishing: por que passkeys e FIDO2

Nem todo MFA oferece a mesma proteção contra ATO. OTP por SMS, OTP por e-mail e push notification simples ainda dependem de um segredo ou aprovação que pode ser interceptado, redirecionado ou socialmente extraído. A NIST 800-63B desencoraja explicitamente o uso de SMS como canal restrito (out-of-band) por sua vulnerabilidade a SIM swap e interceptação, e classifica como phishing-resistant apenas autenticadores que vinculam a autenticação à origem (channel binding).

Passkeys, baseadas em FIDO2/WebAuthn, atendem a esse requisito. A chave privada nunca deixa o dispositivo do usuário, a autenticação é assinada criptograficamente e atrelada ao domínio (origin), e não existe segredo compartilhado que possa ser phishado ou reutilizado. Isso anula de uma vez credential stuffing, phishing com proxy reverso e SIM swap como caminhos para o login. Em termos de NIST 800-63B, autenticadores criptográficos com verificador resistente a phishing são o que viabiliza AAL2/AAL3 sem as fraquezas do OTP.

Para um produto de fintech, a recomendação prática é tornar passkeys o método primário e tratar OTP por SMS apenas como fallback de recuperação com fricção e risco adicionais, jamais como segundo fator padrão para operações sensíveis. Step-up authentication, exigindo reautenticação com passkey antes de transferências de alto valor, cadastro de beneficiário ou troca de dados de contato, fecha a lacuna entre autenticar a sessão e autorizar a ação crítica.

A migração não precisa ser abrupta. É viável habilitar passkeys em paralelo, incentivar o registro no onboarding e em pontos de alto engajamento, e reduzir gradualmente a superfície de métodos fracos conforme a adoção cresce, sempre medindo taxas de registro e de sucesso por coorte.

Device fingerprinting, detecção de fraude e resposta

Autenticação forte não elimina a necessidade de avaliar o contexto de cada sessão. Device fingerprinting combina atributos de hardware, navegador e rede para reconhecer dispositivos conhecidos e sinalizar os novos, dando peso a um login que ocorre de um device nunca visto associado àquela conta. Bem implementado, ele reduz fricção para o usuário legítimo (que opera de dispositivos familiares) e a concentra exatamente onde o risco aparece.

Sobre esse contexto opera o motor de detecção de fraude: regras determinísticas para padrões conhecidos (viagem impossível, beneficiário novo de alto valor, velocidade anômala) somadas a modelos de risco que pontuam o comportamento agregado. A resposta deve ser proporcional ao score: liberar transparente para baixo risco, exigir step-up com passkey para risco médio e bloquear ou colocar em revisão manual para risco alto. Esse escalonamento preserva a experiência sem abrir mão da contenção.

Detecção sem resposta operacional é incompleta. Um plano de resposta a ATO precisa de runbooks claros: invalidar sessões ativas, forçar reautenticação, congelar transações pendentes, reverter mudanças de dados de contato, notificar o titular por canal independente e preservar evidências para análise forense e eventual reporte. No Brasil, esse processo se conecta às exigências de segurança cibernética e gestão de incidentes aplicáveis a instituições reguladas pelo Banco Central, incluindo o ecossistema Pix, onde tempestividade e rastreabilidade são esperadas.

Operar essa cadeia, telemetria, detecção e resposta, de forma contínua exige capacidade 24x7 que muitas fintechs em crescimento ainda não têm internamente. É nesse ponto que a Decripte atua como parceira: SOC com monitoramento ininterrupto, correlação de sinais de ATO e fraude, e resposta a incidentes com runbooks acionáveis, integrando-se aos controles de autenticação e antifraude já existentes no produto.

Construindo defesa em profundidade contra ATO

Nenhum controle isolado resolve account takeover, porque cada vetor ataca uma camada diferente. A senha protege contra acesso casual, mas cai no vazamento; o MFA forte protege o login, mas não a autorização da transação; o device fingerprinting contextualiza, mas não autentica. A força está na sobreposição: para ter sucesso, o atacante precisaria contornar várias camadas independentes simultaneamente, o que eleva drasticamente o custo do ataque.

Em termos de OWASP, isso significa endereçar as ameaças automatizadas (credential stuffing, account creation abuse) na borda, falhas de identificação e autenticação no fluxo de login (categoria do OWASP Top 10), e a lógica de negócio na camada transacional. Cada uma exige controles próprios, e o desenho deve assumir que qualquer camada pode falhar isoladamente.

Uma arquitetura madura encadeia: higiene de credenciais (verificação contra bases de senhas vazadas, conforme NIST 800-63B), passkeys como autenticador primário resistente a phishing, device fingerprinting e análise de risco por sessão, step-up authentication para ações sensíveis, monitoramento contínuo com correlação de sinais e um plano de resposta testado. O resultado não é risco zero, mas risco gerenciável e mensurável.

Para fintechs que estão estruturando ou amadurecendo essa postura, a Decripte oferece um plano gratuito para começar o monitoramento e avaliar a superfície de ATO, com caminho de evolução para SOC 24x7 e resposta a incidentes conforme a operação cresce.

Checklist prático

1. 1

   1. Mapeie os vetores e a superfície de ATO

   Inventarie todos os fluxos de autenticação, recuperação de conta, troca de dados de contato e autorização de transação. Identifique onde há dependência de SMS/OTP e onde uma mudança de credencial pode habilitar transferência na mesma sessão.

2. 2

   2. Bloqueie credential stuffing na borda

   Verifique senhas contra bases de vazamentos (NIST 800-63B), aplique rate limiting por conta, IP e device, e implemente detecção de automação seguindo o OWASP Automated Threat Handbook (OAT-008).

3. 3

   3. Adote MFA resistente a phishing

   Implemente passkeys/FIDO2 (WebAuthn) como autenticador primário visando AAL2/AAL3. Rebaixe OTP por SMS a fallback de recuperação com fricção, nunca como segundo fator padrão de operações sensíveis.

4. 4

   4. Implante device fingerprinting e score de risco

   Reconheça dispositivos conhecidos, sinalize novos e combine geolocalização, ASN e telemetria comportamental em um score de risco por sessão para calibrar fricção de forma proporcional.

5. 5

   5. Exija step-up para ações sensíveis

   Force reautenticação com passkey antes de transferências de alto valor, cadastro de beneficiário e troca de e-mail, telefone ou senha. Trate a autorização da ação como evento distinto da autenticação da sessão.

6. 6

   6. Centralize telemetria e monitore 24x7

   Consolide logs de autenticação, device, geolocalização e eventos transacionais em um pipeline de detecção único, com correlação contínua de sinais de ATO e cobertura ininterrupta via SOC.

7. 7

   7. Prepare e teste o runbook de resposta

   Documente passos de contenção (invalidar sessões, congelar transações, reverter mudanças de contato, notificar por canal independente, preservar evidências) e exercite-os, alinhando aos requisitos de incidentes do Banco Central.

Perguntas frequentes