Detección de Granjas de Cuentas en APIs de IA con Señales de Dispositivo y Red (ES)

Una cuenta es una fila en una base de datos. Un dispositivo es un objeto físico por el que alguien pagó.

Esa asimetría es la base de la detección de abuso a nivel de dispositivo, y es la razón por la que una operación de "granjeo" que puede generar 20,000 cuentas de forma gratuita no puede generar 20,000 dispositivos de forma gratuita. En algún lugar, debajo de la capa de cuentas, hay un grupo finito de hardware real, rutas de red reales y un conjunto de trucos utilizados para hacer que ese pequeño grupo parezca grande.

Esos trucos tienen firmas. Esta publicación es un recorrido por los que emite el análisis de dispositivos y red de Didit, lo que realmente significa cada uno y cómo ponderarlos, por $0.03 por verificación, o incluido en la verificación completa de $0.33.

Puntos clave

• Las operaciones de "granjeo" reutilizan un pequeño sustrato físico detrás de una gran superficie de cuentas. La reutilización es detectable.
• Tres familias de señales importan: duplicación (el mismo dispositivo o dirección, más de una vez), integridad (este no es un cliente normal) y red (esta ruta no es lo que dice ser).
• DEVICE_RECOVERED_HIGH_CONFIDENCE es el código individual de mayor valor para este problema: detecta un dispositivo que regresa después de un borrado, que es el movimiento de regeneración estándar.
• Los códigos de integridad como AUTOMATION_FRAMEWORK_DETECTED y DEVICE_EMULATOR_DETECTED son fuertes por sí solos. Los códigos de duplicación son débiles por sí solos y necesitan corroboración.
• Las acciones de advertencia son configurables por código (rechazar, revisar o registrar), por lo que la escalera de escalada es suya.
• $0.03 por verificación independiente; incluido en el paquete de verificación de $0.33.

Las tres familias de señales

Duplicación: ¿he visto esto antes?

Código	Significado
DUPLICATED_DEVICE_FINGERPRINT	El mismo dispositivo aparece detrás de más de una verificación
DUPLICATED_IP_ADDRESS	La misma dirección aparece detrás de más de una verificación
DEVICE_RECOVERED_HIGH_CONFIDENCE	Un dispositivo visto previamente que regresa después de un reinicio o reinstalación
EXPECTED_IP_ADDRESS_MISMATCH	La dirección difiere de la esperada para esta sesión

Didit hace una distinción explícita entre un dispositivo duplicado y un dispositivo recuperado, y la diferencia es la parte interesante.

Un dispositivo duplicado son dos verificaciones del mismo dispositivo, algo común y a menudo inocente. Una tableta familiar. Una estación de trabajo compartida. Un agente de soporte ayudando a un usuario a través de un flujo.

Un dispositivo recuperado es un dispositivo que fue borrado, reiniciado o que tuvo la aplicación reinstalada, y ahora ha regresado. Didit aún lo reconoce.

Para el "granjeo" de cuentas, ese segundo caso es la señal de oro. El procedimiento operativo estándar después de una prohibición es reiniciar el dispositivo y registrarse nuevamente; eso es precisamente lo que hace que una red "hidra" se regenere más rápido de lo que se poda. DEVICE_RECOVERED_HIGH_CONFIDENCE en una cuenta nueva dice: este hardware ha estado aquí antes, bajo una cuenta diferente, y alguien se tomó la molestia de intentar borrar eso. Casi nada legítimo produce esa combinación en una primera verificación.

Integridad: ¿es este un cliente normal?

Código	Significado
AUTOMATION_FRAMEWORK_DETECTED	El cliente está siendo manejado por automatización, no por una persona
DEVICE_EMULATOR_DETECTED	Un dispositivo emulado en lugar de hardware real
DEVICE_ROOTED_OR_JAILBROKEN	El modelo de seguridad del sistema operativo ha sido eliminado
DEVICE_RUNTIME_HOOKING_DETECTED	La instrumentación en tiempo de ejecución está adjunta al proceso
DEVICE_APP_TAMPERED	El binario de la aplicación ha sido modificado
DEVICE_DEBUGGER_ATTACHED	Un depurador está adjunto
DEVICE_INTEGRITY_SIGNALS_MISSING	Faltan las señales de integridad esperadas

Esta familia es cualitativamente diferente de la duplicación, y vale la pena tener claro por qué: estos códigos describen la intención.

DUPLICATED_IP_ADDRESS puede ocurrirle a cualquiera en una universidad. AUTOMATION_FRAMEWORK_DETECTED en un flujo de verificación significa que alguien está realizando una verificación de identidad con un script. DEVICE_EMULATOR_DETECTED significa que el "teléfono" que completa su verificación es un software que se ejecuta en un servidor, la forma más barata de hacer que una máquina parezca cien. DEVICE_APP_TAMPERED significa que el binario del cliente ha sido modificado, que es lo que se hace cuando se quiere que informe cosas que no son ciertas.

Las granjas de emuladores y los marcos de automatización son las herramientas industriales del "granjeo" de cuentas. Cuando aparecen en una verificación, la explicación inocente es escasa.

DEVICE_INTEGRITY_SIGNALS_MISSING es el sutil. No dice que algo esté mal, dice que las señales que le dirían que nada está mal no llegaron. Trate la ausencia como un negativo débil en lugar de un neutro, porque suprimir la telemetría es en sí mismo una técnica.

Red: ¿es esta ruta lo que dice ser?

Código	Significado
PRIVATE_NETWORK_DETECTED	Una ruta de red privada o anonimizadora
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	La geografía del documento y la red no coinciden
IP_LOCATION_NOT_ALLOWED	La ubicación está fuera de su política configurada
IP_ADDRESS_IN_BLOCKLIST / IP_ADDRESS_IN_ALLOWLIST	La dirección coincidió con una de sus listas
DEVICE_FINGERPRINT_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_ALLOWLIST	El dispositivo coincidió con una de sus listas
LOCATION / NO_ACTION	Informativo

Las señales de red son la familia más débil y deben ponderarse en consecuencia. Los desarrolladores conscientes de la privacidad utilizan redes anonimizadoras de forma rutinaria, y la población de una API de IA es más técnica que la media; se espera una tasa base más alta de uso de redes privadas, no es sospechoso.

COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP es más útil que la geografía pura porque es una contradicción en lugar de una ubicación. La gente viaja y la gente se reubica, por lo que no es condenatorio por sí solo, pero combinado con una señal de duplicación se agudiza considerablemente.

Los códigos de lista de bloqueo y lista de permitidos son la mitad de la aplicación, cubiertos en profundidad en la publicación sobre la propagación de la lista de bloqueo.

Ponderación: qué es fuerte, qué es débil

El error de implementación más común es tratar cada advertencia como equivalente. No son ni remotamente equivalentes.

Fuertes por sí solos — base razonable para rechazar o revisar a fondo:

DEVICE_EMULATOR_DETECTED · AUTOMATION_FRAMEWORK_DETECTED · DEVICE_APP_TAMPERED · DEVICE_RUNTIME_HOOKING_DETECTED · IP_ADDRESS_IN_BLOCKLIST · DEVICE_FINGERPRINT_IN_BLOCKLIST

Fuertes en contexto — escalar cuando se combinan con cualquier otra cosa:

DEVICE_RECOVERED_HIGH_CONFIDENCE · DEVICE_ROOTED_OR_JAILBROKEN · COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP

Débiles solos — corroborar antes de actuar:

DUPLICATED_IP_ADDRESS · PRIVATE_NETWORK_DETECTED · DUPLICATED_DEVICE_FINGERPRINT · DEVICE_INTEGRITY_SIGNALS_MISSING

El patrón es consistente: los códigos que describen la manipulación deliberada del cliente son fuertes; los códigos que describen recursos compartidos son débiles. Los recursos compartidos tienen miles de explicaciones inocentes. Un binario modificado no.

Configuración de la respuesta

Las acciones de advertencia son configurables por código, por lo que puede construir una verdadera escalera de escalada en lugar de una única puerta de aprobación/rechazo.

Un valor predeterminado viable para una API de IA:

• Rechazar en DEVICE_APP_TAMPERED, DEVICE_EMULATOR_DETECTED, AUTOMATION_FRAMEWORK_DETECTED y cualquier coincidencia con la lista de bloqueo. Una coincidencia con la lista de bloqueo fuerza un rechazo por diseño.
• Revisar en DEVICE_RECOVERED_HIGH_CONFIDENCE y en DEVICE_ROOTED_OR_JAILBROKEN.
• Solo registrar en DUPLICATED_IP_ADDRESS, PRIVATE_NETWORK_DETECTED y LOCATION — capturarlos para correlación, pero nunca actuar sobre ellos solos.

Los códigos solo registrados no se desperdician. Son lo que hace posible una investigación seis semanas después, cuando su capa de tráfico marca una cuenta y necesita saber qué más toca. Recopilarlos en el nivel más barato, como se describe en la arquitectura de acceso por niveles de riesgo, es lo que hace que la correlación posterior funcione en absoluto.

Lectura de las señales en una sesión

Los resultados de dispositivos y red llegan con la decisión de la sesión:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Dirija las advertencias, no solo el estado de nivel superior. Una sesión aprobada que contenga DUPLICATED_DEVICE_FINGERPRINT y DEVICE_RECOVERED_HIGH_CONFIDENCE está aprobada y merece un examen más detenido, y si solo lee el estado, nunca lo sabrá.

Didit también muestra coincidencias entre sesiones, que es cómo se pasa de una sola advertencia al conjunto de otras sesiones que comparten ese dispositivo o dirección. Ese es el pivote de una cuenta a un clúster.

Casos de uso

Plataformas de API de IA que recopilan señales de dispositivos y red en el nivel de pago más barato para que los datos de correlación existan antes de que sean necesarios.

Programas de prueba gratuita y crédito donde las granjas de emuladores son el vector de abuso dominante y DEVICE_EMULATOR_DETECTED por sí solo elimina la mayor parte del volumen.

Mercados y plataformas de servicios bajo demanda que detectan vendedores o mensajeros eliminados que regresan con hardware borrado.

iGaming que aplica reglas de cuenta única y autoexclusión, donde la recuperación de dispositivos es la evasión estándar.

Preguntas frecuentes

¿Funciona esto en la web o solo en aplicaciones móviles?

Ambos. La profundidad de las señales de integridad es mayor en dispositivos móviles nativos, donde el sistema operativo expone más; códigos como DEVICE_ROOTED_OR_JAILBROKEN y DEVICE_APP_TAMPERED son conceptos de aplicaciones nativas. Las sesiones web aún producen señales de correlación de red y dispositivos.

¿Puede un atacante decidido anular la huella digital del dispositivo?

Sí, parcialmente, por eso es una familia entre varias en lugar de la respuesta completa. El objetivo no es la identificación perfecta, es el costo. Cada capa de evasión que agrega un operador les cuesta dinero y tiempo de ingeniería, y las herramientas de evasión en sí mismas activan los códigos de integridad. Un atacante que ha derrotado la huella digital del dispositivo suele ser visible en una de las otras familias de señales.

¿Qué compra realmente $0.03?

Una verificación de análisis de IP y dispositivo en una sesión, que devuelve el catálogo completo de advertencias. Se factura por verificación exitosa sin mínimos, y ya está incluido cuando ejecuta el paquete de verificación completo de $0.33.

¿Es suficiente una señal de red privada para rechazar?

No, y rechazar por ello le costará desarrolladores reales. En una audiencia técnica, las redes anonimizadoras son comunes. Regístrelo y úselo como corroboración.

¿Cómo se relaciona esto con la detección de destilación en el tráfico?

No detecta la destilación. Las señales de dispositivos y red le informan sobre el cliente y la cuenta, nunca sobre el contenido del tráfico de su API. La detección semántica es una capa separada que reside en su propio stack. Estas señales le indican cuántas cuentas está ejecutando un operador; su capa de tráfico le dice qué están haciendo con ellas.

¿Listo para empezar?

El análisis de dispositivos y red es una única verificación en cualquier sesión de verificación.

• Lea la documentación — Descripción general del análisis de IP y dispositivos y el catálogo completo de advertencias.
• Vea el producto — Verificación de usuario.
• Consulte los precios — $0.03 por verificación, incluido en el paquete de $0.33, sin mínimos.
• Empiece gratis — business.didit.me, 500 verificaciones KYC al mes sin costo.