Por qué las reglas de fraude dejan de funcionar (y cómo saber si las tuyas ya no sirven)

Basado en patrones de ataque reales que nuestros analistas investigaron, con los detalles modificados.

Hace unas semanas estaba revisando las reglas de fraude de una entidad de crédito y una de ellas parecía estar perfectamente sana. Sin alertas. Sin quejas del equipo de revisión. Se había diseñado para detener una ola de solicitudes de préstamo automatizadas y, según el panel de control, parecía haber cumplido su función.

Pero en realidad no estaba detectando absolutamente nada.

Entonces, ¿por qué dejan de funcionar las reglas de fraude? La mayoría de las veces, el atacante cambia una de las señales de las que depende la regla. Una regla que necesita un conjunto fijo de condiciones para activarse de forma conjunta no puede funcionar si una de ellas desaparece. 

Por eso, una regla silenciosa puede significar dos cosas muy distintas: o bien el ataque se detuvo, o bien la regla dejó de funcionar.

Resumen rápido

• Una regla de fraude de una entidad de crédito dejó de detectar un ataque de solicitudes automatizadas porque el atacante eliminó una de las tres señales que la regla necesitaba. En aproximadamente 290,000 evaluaciones, no coincidió con ninguna.

• Nadie se dio cuenta, porque los paneles de control muestran lo que las reglas detectan, no lo que se les escapa.

• Flexibilizar la regla no era la solución, ya que habría enviado a revisión o a verificación adicional a muchos clientes reales.

• Lo que detectó el ataque fueron los datos puros del dispositivo y del comportamiento, no las señales de riesgo estándar.

• Para protegerte, activa alertas para las reglas que se queden en silencio, verifica cada condición de una regla por separado y afronta cada ataque con más de una regla.

Qué sucedió

A principios del verano, esta entidad de crédito sufrió un ataque de solicitudes de préstamo automatizadas. El equipo creó una regla que requería tres señales al mismo tiempo: una configuración de navegador específica, un indicador de automatización y un error de red. Era una regla lógica y se adaptaba al ataque para el que fue diseñada.

Luego, la misma operación volvió a la carga, pero con algunos cambios:

• Utilizaron un navegador modificado que se ejecutaba en computadoras Windows reales.

• Cada solicitud provenía de su propia conexión proxy residencial.

• Los datos de identidad se generaron y pegaron en el formulario, no se escribieron a mano.

Durante unas cuatro semanas, enviaron cerca de 1,650 solicitudes. Esto era fraude con bots, pero no del tipo descuidado.

El cambio clave fue que el atacante dejó de activar una de las tres señales. Las otras dos señales seguían apareciendo en aproximadamente el 97% o más del tráfico de ataque. La tercera aparecía en solo el 1%. Como la regla requería las tres, nunca se cumplía. En unas 290,000 evaluaciones, el número de coincidencias fue cero.

Para que quede claro: ninguna de estas solicitudes llegó a la fase de aprobación final. Esta no es una historia sobre pérdida de dinero, sino sobre cómo una capa de defensa se quedó en silencio mientras todos asumían que seguía funcionando.

¿Por qué dejó de activarse la regla?

Esta es la debilidad básica de la detección de fraudes basada en reglas. Piensa en la regla como "A y B y C". Las tres tienen que aparecer. Si C desaparece, A y B pueden estar presentes en cada solicitud y la regla aun así no se activará.

La solución obvia es flexibilizarla: eliminar la condición que falta o cambiarla a "A o B". Eso suele empeorar las cosas, porque algunas señales por sí solas son demasiado comunes. Muchos clientes legítimos también activan un indicador de automatización. Para la base de clientes de esta entidad, una regla de tipo "A o B" habría enviado a revisión a una gran parte de los solicitantes reales. Si flexibilizas la regla, cambias un problema de fraude por uno de fricción para el usuario.

Así que terminas atrapado entre dos malas opciones: las reglas estrictas se vuelven obsoletas y las reglas flexibles saturan la fila de revisión.

¿Por qué nadie se dio cuenta?

Nadie pasó esto por alto por falta de atención. Hubo varios factores que dificultaron detectarlo:

• La falta de alertas parece una buena noticia. La mayoría de los motores de reglas de fraude informan sobre lo que se activa, y los paneles muestran lo que las reglas detectan, no lo que se les escapa.

• Cada dispositivo era completamente nuevo el día que realizaba la solicitud, por lo que no había un historial en el cual basarse.

• Cada solicitud provenía de su propia conexión, por lo que los controles de velocidad no tenían nada que contabilizar.

• Los datos de identidad parecían de personas reales.

¿Qué debes hacer cuando una regla de fraude deja de activarse?

Las reglas siempre reaccionan a un patrón de ataque. Por lo tanto, cuando una regla deja de activarse, suele deberse a una de dos razones: o el patrón para el que fue diseñada ya no existe (un poco como los bancos que siguen teniendo guardias de seguridad aunque los robos tradicionales ya casi no ocurren), o el atacante cambió algo.

Para averiguar cuál es el caso, desgloso la regla. Reviso qué sigue marcando alertas y qué no, y lo comparo con la firma del ataque. En este caso, dos de las tres condiciones seguían activándose en casi todo el tráfico de ataque. Eso me indicó que el ataque no había desaparecido; simplemente había esquivado una condición.

Por eso siempre sugiero tener más de una regla. Ataca la firma del fraude desde múltiples ángulos, de modo que si el estafador cambia una cosa, las otras reglas aún puedan detectarlo.

Qué fue lo que lo detectó

Las señales de riesgo estándar no ayudaron mucho en este caso. Solo una de ellas seguía activándose a gran escala, y también lo hace con mucho tráfico normal, por lo que no podía aislar este ataque por sí sola.

Lo que reveló la situación fueron los datos puros de comportamiento y del dispositivo que recopila Oscilar. Cuando comparamos el tráfico del ataque con las solicitudes normales, destacaron algunos detalles que un navegador real en una computadora real simplemente no produce:

• Faltaba un componente que cualquier instalación estándar de Chrome para escritorio reporta.

• La ventana del navegador tenía el mismo tamaño en casi todas las solicitudes, aunque las pantallas detrás de ellas variaban mucho de tamaño.

• El cursor se movía en pasos espaciados uniformemente, de forma robótica, no de la manera en que una persona mueve el mouse.

• En solo una muestra que extrajimos, apareció exactamente la misma secuencia de clics y pulsaciones de teclas en 285 solicitudes distintas. No hay dos personas que completen un formulario de la misma manera; un script lo hace idéntico cada vez.

La nueva regla se enfoca en una condición que una instalación normal de Chrome nunca produce. La probamos con más de 75,000 solicitudes durante unos 3 meses y no coincidió con nada fuera del ataque. Además, se ejecuta al inicio de la solicitud, antes de que se envíe cualquier dato de identidad.

¿Cómo sabes si una regla de fraude sigue funcionando?

No necesitas un gran proyecto para comprobarlo. Unas pocas preguntas pueden ayudarte mucho:

• ¿Cuándo fue la última vez que se activó cada una de tus reglas? Una regla que de repente se queda en silencio merece una revisión.

• ¿Recibes alertas cuando baja la tasa de activación de una regla? La mayoría de los equipos configuran alertas para cuando las reglas se activan demasiado. Casi nadie alerta cuando una regla se queda en silencio.

• Para las reglas que necesitan varias condiciones a la vez, ¿con qué frecuencia se activa cada condición por separado? Si una ha bajado casi a cero, la regla no se podrá activar.

• ¿Hay reglas silenciosas junto a un volumen creciente de aprobaciones en un segmento? Vale la pena investigar esa combinación.

• ¿Has vuelto a probar las reglas más antiguas contra ataques recientes, y no solo contra aquellos para los que fueron diseñadas?

¿Cómo diseñar reglas de fraude que no queden obsoletas?

Ninguna regla dura para siempre. Los atacantes se adaptan; ese es su trabajo. Pero algunos hábitos ayudan a que las reglas resistan mejor el paso del tiempo:

• Usa más de una regla contra el mismo ataque, desde diferentes ángulos, para que un solo cambio no derribe toda tu defensa.

• Combina señales de dispositivo, red y comportamiento, y monitorea cada elemento por separado, no solo la regla combinada.

• Enfócate en el comportamiento en lugar de en las direcciones IP o redes, ya que estas cambian constantemente.

• Mide el costo de los falsos positivos antes de implementar una regla.

• Observa el comportamiento de las nuevas reglas durante un tiempo antes de dejar que bloqueen algo.

Cuando las señales estándar dejan de funcionar, los datos puros de dispositivo y comportamiento revelan la realidad. 

Eso fue lo que detectó este ataque, y es la capa sobre la que se basa la inteligencia de dispositivos de Oscilar.

Además, abordamos el monitoreo como un trabajo de todo el sistema, no regla por regla. Eso significa estar atentos a las reglas que se quedan en silencio, no solo a las que generan mucho ruido. También significa probar las nuevas reglas con tráfico histórico antes de que se activen, para saber qué detectarán y qué costo tendrán en fricción antes de que las experimente un solo cliente real.

¿Quieres ver cómo se ve tu propio tráfico a ese nivel? Prueba nuestro escáner de fraude.