Por que as Regras Antifraude Deixam de Funcionar (e Como Saber se as Suas Pararam)

Baseado em padrões de ataque reais que nossos analistas investigaram, com detalhes alterados.

Algumas semanas atrás, eu estava analisando as regras de fraude de uma instituição de crédito e uma delas parecia perfeitamente saudável. Sem alertas. Sem reclamações da equipe de revisão. Ela tinha sido criada para conter uma onda de solicitações de empréstimo automatizadas e, pelo painel de controle, parecia ter cumprido seu papel.

Ela simplesmente não estava detectando absolutamente nada.

Então, por que as regras de fraude param de funcionar? Na maioria das vezes, o invasor alterou um dos sinais dos quais a regra depende. Uma regra que precisa de um conjunto fixo de condições acontecendo ao mesmo tempo não consegue ser acionada se uma delas desaparecer. 

É por isso que uma regra silenciosa pode significar duas coisas muito diferentes: ou o ataque parou, ou a regra parou.

Resumo rápido

• A regra de fraude de uma instituição de crédito parou de detectar um ataque de solicitação automatizada porque o invasor removeu um dos três sinais que a regra exigia. Em cerca de 290.000 avaliações, ela não detectou nada.

• Ninguém percebeu, porque os painéis mostram o que as regras detectam, não o que elas deixam passar.

• Tornar a regra mais flexível não era a solução. Isso teria direcionado muitos clientes reais para revisão ou validação extra.

• O que de fato detectou o ataque foram os dados brutos de dispositivo e comportamento, e não os sinais de risco padrão.

• Para se proteger, configure alertas para regras que ficarem silenciosas, verifique cada condição de uma regra de forma isolada e enfrente cada ataque com mais de uma regra.

O que aconteceu

No início do verão, essa instituição de crédito foi atingida por solicitações de empréstimo automatizadas. A equipe criou uma regra que exigia três sinais simultâneos: uma configuração específica de navegador, um sinalizador de automação e um erro de rede. Era uma regra razoável e se ajustava bem ao ataque para o qual foi escrita.

Depois, a mesma operação voltou, mas com algumas mudanças:

• Eles usaram um navegador modificado rodando em computadores Windows reais.

• Cada solicitação vinha através de sua própria conexão proxy residencial.

• Os dados de identidade eram gerados e colados no formulário, em vez de digitados.

Ao longo de cerca de quatro semanas, eles enviaram aproximadamente 1.650 solicitações. Tratava-se de fraude por bot, mas não daquela forma grosseira.

A mudança principal foi que o invasor parou de acionar um dos três sinais. Os outros dois sinais ainda apareciam em cerca de 97% ou mais do tráfego de ataque. O terceiro aparecia em cerca de 1%. Como a regra exigia os três, ela nunca era acionada. Em cerca de 290.000 avaliações, ela não detectou nada.

Vale esclarecer uma coisa: nenhuma dessas solicitações chegou à fase final de aprovação. Esta não é uma história sobre dinheiro perdido, mas sim sobre uma camada de defesa que silenciou enquanto todos presumiam que ela ainda estava funcionando.

Por que a regra parou de funcionar?

Essa é a fraqueza básica da detecção de fraudes baseada em regras. Pense na regra como "A e B e C". Todos os três precisam aparecer. Se C desaparecer, A e B podem estar presentes em cada uma das solicitações e, mesmo assim, a regra não será acionada.

A correção óbvia seria torná-la mais flexível: remover a condição ausente ou mudá-la para "A ou B". Mas isso geralmente piora as coisas, porque alguns sinais isolados são comuns demais. Muitos clientes legítimos também acionam um sinalizador de automação. Para a base de clientes dessa instituição, uma regra "A ou B" teria enviado uma enorme quantidade de solicitantes reais para revisão. Ao flexibilizar a regra, você troca um problema de fraude por um problema de fricção para o cliente.

Assim, você acaba preso entre duas opções ruins: regras rígidas que ficam obsoletas ou regras flexíveis que inundam a fila de análise.

Por que ninguém percebeu?

Ninguém deixou passar isso por falta de atenção. Alguns fatores dificultaram a visualização:

• A ausência de alertas parece uma boa notícia. A maioria dos motores de regras de fraude relata o que é acionado, e os painéis mostram o que as regras detectam, não o que deixam passar.

• Cada dispositivo era totalmente novo no dia em que fazia a solicitação, então não havia histórico a ser analisado.

• Cada solicitação vinha de sua própria conexão, logo as verificações de frequência não tinham o que contar.

• Os dados de identidade pareciam de pessoas reais.

O que fazer quando uma regra de fraude para de ser acionada?

As regras sempre reagem a um padrão de ataque. Portanto, quando uma regra para de funcionar, geralmente é por um de dois motivos: ou o padrão para o qual ela foi criada não existe mais (assim como os bancos ainda têm guardas de segurança mesmo que assaltos à moda antiga quase não aconteçam mais) ou o invasor mudou de tática.

Para descobrir qual é o caso, eu desmembro a regra. Verifico o que ainda está gerando alertas e o que não está, e comparo isso com a assinatura do ataque. Nesse caso, duas das três condições ainda estavam ativas em quase todo o tráfego de ataque. Isso me mostrou que o ataque não tinha sumido. Ele apenas tinha desviado de uma das condições.

É por isso também que sempre sugiro usar mais de uma regra. Ataque a assinatura de fraude por múltiplos ângulos, pois se o fraudador mudar uma coisa, as outras regras ainda o detectarão.

O que detectou o ataque

Os sinais de risco padrão não ajudaram muito aqui. Apenas um deles ainda funcionava em escala, e ele também era acionado em muito tráfego legítimo, ou seja, não conseguia isolar o ataque por si só.

O que revelou a situação real foram os dados brutos de dispositivo e comportamento da Oscilar que estavam por trás. Quando comparamos o tráfego de ataque com as solicitações normais, alguns pontos se destacaram que um navegador real em um computador real simplesmente não produz:

• Faltava um componente que toda instalação padrão do Chrome para desktop apresenta.

• A janela do navegador tinha o mesmo tamanho em quase todas as solicitações, embora as telas reais por trás delas variassem muito de tamanho.

• O cursor se movia em etapas uniformes e robóticas, e não da maneira como uma pessoa move o mouse.

• Em apenas uma amostra que analisamos, exatamente a mesma sequência de cliques e teclas digitadas apareceu em 285 solicitações distintas. Duas pessoas não preenchem um formulário da mesma maneira. Um script faz isso de forma idêntica todas as vezes.

A nova regra foca em uma condição que uma instalação normal do Chrome nunca produz. Nós a testamos contra mais de 75.000 solicitações ao longo de cerca de 3 meses, e ela não gerou falsos positivos fora do ataque. Além disso, ela roda logo no início da solicitação, antes mesmo do envio de qualquer dado de identidade.

Como saber se uma regra de fraude ainda está funcionando?

Você não precisa de um grande projeto para fazer essa verificação. Algumas perguntas simples ajudam bastante:

• Quando cada uma de suas regras foi acionada pela última vez? Uma regra que de repente ficou silenciosa merece atenção.

• Você recebe alertas quando a taxa de disparo de uma regra cai? A maioria das equipes define alertas para regras que disparam demais. Quase ninguém cria alertas para quando uma regra silencia.

• Para regras que exigem várias condições simultâneas, com que frequência cada condição é acionada de forma isolada? Se uma delas caiu para quase zero, a regra inteira não vai funcionar.

• Há regras silenciosas coexistindo com um aumento no volume de aprovações em algum segmento? Vale a pena investigar essa combinação.

• Você testou novamente as regras mais antigas contra ataques recentes, e não apenas contra aqueles para os quais foram criadas?

Como criar regras de fraude que não fiquem obsoletas?

Nenhuma regra dura para sempre. Os invasores se adaptam; esse é o trabalho deles. No entanto, alguns hábitos ajudam as regras a resistirem por mais tempo:

• Use mais de uma regra contra o mesmo ataque, por ângulos diferentes, para que uma única mudança não derrube toda a sua defesa.

• Combine sinais de dispositivo, rede e comportamento, e monitore cada elemento individualmente, não apenas a regra combinada.

• Foque no comportamento em vez de endereços ou redes. Esses dados mudam constantemente.

• Meça o impacto de falsos positivos antes que uma regra entre em produção.

• Acompanhe as novas regras por um período antes de permitir que elas bloqueiem qualquer ação.

Quando os sinais padrão param de funcionar, os dados brutos de comportamento e de dispositivos revelam o cenário real. 

Foi isso que detectou esse ataque, e é essa a camada em que se baseia a inteligência de dispositivos da Oscilar.

Também tratamos o monitoramento como um processo de sistema completo, e não regra por regra. Isso significa acompanhar regras que ficam silenciosas, e não apenas as que geram muito ruído. Significa também testar novas regras contra o histórico de tráfego antes de colocá-las no ar, para que você saiba o que elas vão detectar e o quanto vão impactar a experiência antes que um único cliente real passe por elas.

Quer ver como é o seu próprio tráfego nesse nível de detalhe? Teste nosso scanner de fraude.