Basado en patrones de ataque reales que investigaron nuestros analistas (se han modificado los detalles).

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

Sin embargo, no estaba detectando absolutamente nada.

Entonces, ¿por qué dejan de funcionar las reglas de fraude? En la mayoría de los casos, porque el atacante cambió una de las señales de las que depende la regla. Una regla que necesita que se den varias condiciones fijas al mismo tiempo no se puede activar si falta una sola de ellas. 

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

En resumen

• La regla de fraude de una entidad de préstamo dejó de detectar un ataque de solicitudes automatizadas porque el atacante eliminó una de las tres señales que la regla necesitaba. De unas 290 000 evaluaciones, la regla coincidió con cero casos.

• 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 habituales.

• Para protegerse, configure alertas para las reglas que dejen de activarse, compruebe cada condición de una regla por separado y afronte cada ataque con más de una regla.

Qué ocurrió

A principios de verano, esta entidad de préstamo sufrió una oleada de solicitudes automatizadas de crédito. El equipo creó una regla que requería tres señales simultáneas: una configuración de navegador específica, un indicador de automatización y un error de red. Era una regla razonable y se ajustaba perfectamente al ataque para el que fue diseñada.

Pero la misma operación volvió a la carga con algunos cambios:

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

• Cada solicitud se enviaba a través de su propia conexión proxy residencial.

• Los datos de identidad se generaban y se pegaban en el formulario, no se escribían a mano.

Durante unas cuatro semanas, enviaron unas 1650 solicitudes. Se trataba de un fraude con bots, pero no de uno descuidado.

El cambio clave fue que el atacante dejó de activar una de las tres señales. Las otras dos seguían apareciendo en aproximadamente el 97% o más del tráfico del ataque. La tercera solo aparecía en el 1%. Como la regla necesitaba las tres para activarse, nunca llegó a completarse. De unas 290 000 evaluaciones, coincidió con cero casos.

Para que quede claro: ninguna de estas solicitudes llegó a la fase de aprobación final. Esta historia no trata de pérdidas de dinero, sino de cómo una capa de defensa dejó de hacer ruido 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 fraude basada en reglas. Piense en la regla como "A y B y C". Tienen que darse las tres. Si desaparece la C, la A y la B pueden estar presentes en cada solicitud, pero la regla seguirá sin activarse.

La solución obvia es flexibilizarla: eliminar la condición que falta o cambiarla a "A o B". Pero 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 flexibiliza la regla, cambiará un problema de fraude por un problema de fricción con el cliente.

Al final, se queda atrapado entre dos malas opciones: las reglas estrictas quedan obsoletas y las reglas flexibles saturan la lista de revisión.

¿Por qué nadie se dio cuenta?

Nadie pasó esto por alto por falta de atención. Varias razones dificultaron verlo:

• Que no haya alertas suele parecer 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 hacía la solicitud, por lo que no había un historial en el que basarse.

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

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

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

Las reglas siempre responden a un patrón de ataque. Por tanto, cuando una regla deja de activarse, suele deberse a una de dos cosas: o bien el patrón para el que se diseñó ya no existe (como los bancos que siguen teniendo guardias de seguridad aunque apenas haya atracos de la vieja escuela), o bien el atacante cambió algo.

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

Por eso siempre sugiero utilizar más de una regla. Aborde el patrón del fraude desde varios ángulos para que, si el estafador cambia una cosa, las demás sigan detectándolo.

Lo que permitió detectarlo

Las señales de riesgo habituales 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 analiza Oscilar. Cuando comparamos el tráfico del ataque con las solicitudes normales, destacaron varios detalles que un navegador real en una computadora real sencillamente no genera:

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

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

• El cursor se movía en pasos espaciados uniformemente, de forma mecánica, no como lo haría una persona con un ratón.

• En solo una muestra que tomamos, apareció exactamente la misma secuencia de clics y pulsaciones de teclas en 285 solicitudes distintas. No hay dos personas que rellenen un formulario de la misma manera. Un programa automatizado lo hace siempre de forma idéntica.

La nueva regla se basa 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 principio de la solicitud, antes de que se envíe ningún dato de identidad.

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

No necesita un gran proyecto de investigación para comprobarlo. Unas pocas preguntas bastarán:

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

• ¿Recibe 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, pero casi nadie lo hace cuando una regla deja de sonar.

• En el caso de reglas que requieren varias condiciones simultáneas, ¿con qué frecuencia se activa cada condición por separado? Si una ha bajado casi a cero, la regla no podrá activarse.

• ¿Hay reglas inactivas que coincidan con un aumento en el volumen de aprobaciones en un segmento concreto? Vale la pena investigar esa combinación.

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

¿Cómo crear reglas de fraude que no queden obsoletas?

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

• Utilice más de una regla contra el mismo ataque, desde diferentes ángulos, para que un solo cambio no tire abajo toda su defensa.

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

• Céntrese en el comportamiento en lugar de en direcciones IP o redes, ya que estas cambian constantemente.

• Mida el coste de los falsos positivos antes de implementar una regla.

• Observe 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 comportamiento y del dispositivo revelan la verdad. 

Eso es lo que permitió detectar este ataque, y es la capa en la que se basa la tecnología de análisis de dispositivos de Oscilar.

También tratamos la monitorización como una tarea de todo el sistema, no regla por regla. Eso implica vigilar las reglas que se silencian, no solo las que hacen demasiado ruido. También significa probar las nuevas reglas con el tráfico histórico antes de que se activen, para saber qué detectarán y qué coste tendrán en fricción con el cliente antes de que las experimente el primer usuario real.

¿Quiere ver cómo es su propio tráfico a ese nivel? Pruebe nuestro escáner de fraude.