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

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

Mas ela não estava detectando absolutamente nada.

Então, por que as regras de fraude param de funcionar? Na maioria das vezes, o invasor altera 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 de funcionar.

Resumo da Ópera

• A regra de fraude de um credor parou de detectar um ataque de solicitação automatizada porque o invasor removeu um dos três sinais de que a regra precisava. Em cerca de 290.000 avaliações, ela não encontrou nenhuma correspondência.

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

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

• 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 individualmente e enfrente cada ataque com mais de uma regra.

O que aconteceu

No início do verão, este credor foi alvo de solicitações de empréstimo automatizadas. A equipe criou uma regra que exigia três sinais ao mesmo tempo: 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 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, não digitados.

Durante cerca de quatro semanas, eles enviaram aproximadamente 1.650 solicitações. Era fraude por robô (bot), mas não de forma amadora.

A mudança fundamental 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 do ataque. O terceiro aparecia em apenas 1%. Como a regra precisava dos três, ela nunca era acionada. Em cerca de 290.000 avaliações, ela não encontrou nenhuma correspondência.

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

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". Os três precisam aparecer. Se o C sumir, A e B podem estar presentes em absolutamente todas as solicitações e, mesmo assim, a regra não será acionada.

A solução óbvia seria torná-la mais flexível: remover a condição ausente ou mudá-la para "A ou B". 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 deste credor, uma regra "A ou B" teria enviado uma enorme quantidade de solicitantes reais para revisão. Se você flexibilizar a regra, apenas trocará um problema de fraude por um problema de atrito.

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

Por que ninguém percebeu?

Ninguém deixou de notar 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 solicitava o empréstimo, então não havia histórico a ser consultado.

• Cada solicitação vinha de sua própria conexão, então as verificações de velocidade não tinham o que contabilizar.

• 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 (como bancos que ainda mantêm guardas de segurança, embora assaltos à moda antiga quase não aconteçam mais) ou o invasor mudou algo.

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

É por isso também que sempre sugiro mais de uma regra. Ataque a assinatura da fraude por vários ângulos; assim, se o fraudador mudar uma coisa, os outros pontos ainda vão pegá-lo.

O que de fato pegou o ataque

Os sinais de risco padrão não ajudaram muito aqui. Apenas um deles ainda era acionado em escala, e ele também ocorre em muito tráfego legítimo, de modo que não conseguia separar este ataque sozinho.

O que revelou a verdade foram os dados brutos de dispositivo e comportamento da Oscilar por trás de tudo. Quando comparamos o tráfego do ataque com solicitações normais, alguns detalhes se destacaram — coisas 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 passos uniformemente espaçados, como uma máquina, diferente do movimento humano de um mouse.

• Em apenas uma amostra que coletamos, a exata mesma sequência de cliques e digitação apareceu em 285 solicitações separadas. Não existem duas pessoas que preencham um formulário exatamente do mesmo jeito. 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 gera. Nós a testamos em mais de 75.000 solicitações ao longo de cerca de 3 meses, e ela não deu nenhum falso positivo fora do ataque. Ela também roda logo no início da solicitação, antes mesmo que qualquer dado de identidade seja enviado.

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

Você não precisa de um grande projeto para verificar isso. Algumas perguntas simples já ajudam muito:

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

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

• Para regras que precisam de várias condições ao mesmo tempo, com que frequência cada condição é acionada sozinha? Se uma delas caiu para quase zero, a regra não conseguirá funcionar.

• Existe alguma regra silenciosa operando ao lado de um volume crescente de aprovações em um determinado segmento? Vale a pena investigar essa combinação.

• Você retestou 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. Mas alguns hábitos ajudam as regras a resistirem por mais tempo:

• Use mais de uma regra contra o mesmo ataque, de â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 de IP ou redes. Esses elementos mudam constantemente.

• Meça o custo de falsos positivos antes de colocar uma regra em produção.

• Monitore as novas regras por um tempo antes de permitir que elas bloqueiem qualquer coisa.

Quando os sinais padrão param de funcionar, os dados brutos de dispositivo e comportamento revelam a verdade. 

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

Também tratamos o monitoramento como um processo de todo o sistema, 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 tráfego histórico antes de colocá-las em produção, para que você saiba o que elas vão detectar e qual será o custo em atrito antes mesmo que um único cliente real as encontre.

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