Casos de Uso

Como o sucesso se parece, em três fatias de tráfego real de produção.

Os números na nossa seção de resultados — uma redução mediana de cerca de 47% em chargebacks, taxa de falso positivo abaixo de meio por cento, verificação respondendo em poucos milissegundos — vêm de integrações como as abaixo. Os casos aqui são composições anonimizadas; os padrões são reais.

Marketplaces

O problema: anéis de contas falsas criando dezenas de contas para fazer review-bombing, manipular rankings de vendedores ou abusar de promoções de bônus de boas-vindas.

O sinal: doze contas criadas em duas horas, todas de conexões diferentes — mas com sinais de navegador e adulteração apontando para um único cluster automatizado.

Como o sinal se compõe

Um único cadastro de uma conexão doméstica em um navegador real é nada notável. Doze cadastros de doze conexões domésticas diferentes, no que parece ser o mesmo navegador automatizado com a mesma assinatura de adulteração, é um anel de contas falsas.

As categorias que disparam juntas aqui:

• Automação e bots (01) — assinaturas de navegador headless em toda conta.
• Adulteração de fingerprint (02) — testes de desenho que não correspondem à versão do navegador declarada.
• Abuso de infraestrutura (03) — proxies residenciais vendidos por um operador de fraude conhecido.
• Anomalias comportamentais (06) — formulários de cadastro preenchidos em padrões idênticos, com o mesmo timing.

Nenhuma categoria isolada sinalizaria o anel. O score de risco combinado sinaliza.

A política

O marketplace bloqueia no nível mais alto — o anel, não os clientes — e aumenta o nível para verificação por telefone quando o risco é alto e a confiança é sólida. Todo o restante flui sem obstáculos. Na prática, a política inteira tem algumas linhas de código lendo o nível de risco que a Noxtica retorna.

O resultado

Cadastros falsos caem cerca de 70% dentro de um mês após a integração. A conversão de cadastro de clientes reais permanece inalterada.

Serviços financeiros

O problema: fraude de cartão não presente, especialmente ataques de account-takeover em que o atacante tem os detalhes do cartão, mas não os dispositivos conhecidos do titular.

O sinal: uma sessão cujo perfil não corresponde aos dispositivos conhecidos do titular do cartão. A resposta é verificação step-up, não um bloqueio direto. Clientes reais não veem atrito; anéis de fraude enfrentam uma verificação extra em cada transação.

Como o sinal se compõe

A fraude de cartão não presente usa cada vez mais detalhes de cartão reais e roubados em dispositivos controlados pelo atacante. O dispositivo é o diferencial. Mantemos um perfil por cliente; quando uma transação chega de um perfil que não vimos para aquele cliente, a sinalizamos.

As categorias que disparam juntas aqui:

• Verificações de hardware (05) — o novo dispositivo pode ter uma assinatura gráfica, de áudio ou de memória diferente.
• Abuso de infraestrutura (03) — anéis de fraude frequentemente ficam atrás de rotas de datacenter mesmo quando usam proxies residenciais na frente.
• Anomalias comportamentais (06) — timing de checkout que não corresponde ao histórico do titular.

O sinal de novo dispositivo sozinho não é malicioso — clientes compram telefones, trocam laptops, reinstalam sistemas operacionais. Ponderamos com as outras categorias para separar “cliente em um novo dispositivo” de “atacante com detalhes de cartão roubados”.

A política

Um cliente recorrente em um dispositivo conhecido, abaixo do nível mais alto, segue direto sem atrito. Quando o risco é alto — ou um novo dispositivo aparece em uma transação incomumente grande — a sessão recebe verificação step-up em vez de um bloqueio direto. O viés é sempre para deixar clientes reais completarem a compra.

O resultado

As perdas com chargeback caem cerca de 45 a 50% dentro de três meses. A verificação step-up é vista por apenas uma pequena fração das transações, e a grande maioria delas é concluída com sucesso — clientes reais passando na verificação.

Plataformas sensíveis à identidade

O problema: plataformas sem senha e de sign-on único precisam confirmar que a entidade clicando num link de login é a mesma que o solicitou. Kits de phishing e serviços de link-relay quebram essa premissa.

O sinal: um link clicado a partir de um perfil diferente daquele que o solicitou dispara uma etapa adicional de verificação. Kits de phishing e serviços de link-relay são capturados neste portão.

Como o sinal se compõe

Quando um link de login é solicitado, registramos o perfil solicitante. Quando o link é clicado, verificamos novamente o perfil e comparamos. Se correspondem — mesmo navegador, mesmo dispositivo — o link autentica automaticamente. Se não, tratamos o clique como uma sessão diferente e exigimos uma etapa adicional de verificação.

As categorias que disparam juntas aqui:

• Adulteração de fingerprint (02) — kits de phishing frequentemente rodam navegadores headless cujos perfis não correspondem ao dispositivo real do usuário.
• Anomalias comportamentais (06) — o tempo entre solicitação e clique, a origem do tráfego e como a sessão muda, tudo importa.
• Abuso de infraestrutura (03) — serviços de link-relay tipicamente rodam de infraestrutura de nuvem.

A política

Se o dispositivo que clica corresponde ao dispositivo que solicitou o link, o login funciona automaticamente. Se não, a plataforma exige um segundo fator antes de deixar a sessão prosseguir. A verificação de correspondência é uma comparação simples contra o perfil registrado quando o link foi emitido.

O resultado

O sucesso de phishing contra campanhas de link de login cai drasticamente — tipicamente uma redução de 90% ou mais em ataques bem-sucedidos de relay de credenciais. Usuários reais que legitimamente trocam de dispositivo veem uma etapa adicional de verificação e então entram na lista de dispositivos confiáveis para links futuros.

Padrão: quando bloquear, quando desafiar

Em todos os três casos de uso, a estrutura da política é a mesma:

1. Risco crítico — bloquear com registro. Essas sessões não valem o custo de um desafio.
2. Risco alto — desafiar: verificação step-up, um segundo fator ou revisão manual. Clientes reais passam; bots não.
3. Risco médio — observar. Registre a sessão e a destaque no painel, mas sem adicionar atrito.
4. Risco baixo ou mínimo — permitir. A grande maioria do tráfego.

Essas quatro ações se mapeiam para o modelo de risco de cinco níveis: os dois níveis mais baixos colapsam em “permitir” para quase todos, mas mantê-los separados é útil no painel para entender onde a sua população se encontra.

Leitura relacionada

• Categorias de ameaça — detalhe sobre cada uma das seis categorias que estes casos de uso referenciam.
• Por que calibração, não veredictos — por que a política é sua, não nossa.
• Princípios de engenharia — as restrições operacionais por trás dos padrões.