Geofraude: cuando un usuario finge estar en el país, ciudad o incluso barrio "correcto" para acceder a funciones, bonos o tarifas a las que en realidad no debería tener derecho. En las casas de apuestas esto implica abuso de bonos y cuentas múltiples, en fintech se trata de eludir restricciones regulatorias, y en servicios de streaming se refiere a los derechos sobre el contenido. El escenario es familiar: VPN, proxy móvil, navegador antidetector, emulador de Android y algo de imaginación. La buena noticia es que con frecuencia falta imaginación — y eso es una oportunidad para el antifraude.
A dónde y por qué se suplantan las ubicaciones
Las motivaciones son banales pero constantes. Al jugador le interesan bonos más generosos, al arbitrajista le interesan ofertas baratas, a una tienda "gris" le interesa sortear geocercas de pago. Se suplantan IP mediante VPN/proxy, se enmascara el dispositivo como un navegador "limpio", se ejecuta la aplicación en un emulador o en una VDI corporativa, donde todo parece estéril. Si se explican con claridad los riesgos y se establecen varios "niveles de veracidad", parte de las maniobras caerán por sí solas.
- Abuso de bonos: IP nueva, dispositivo "nuevo", región distinta.
- Elusión regulatoria: acceso desde un país prohibido.
- Discriminación de precios: suplantación de ciudad/país para obtener una tarifa favorable.
Señales a nivel IP: detalles que delatan el esquema
El IP es la primera capa. Sí, muchas bases de geolocalización se equivocan por cientos de kilómetros, pero a nivel de infraestructura hay mucha verdad. Mire más allá de un simple "IP del país correcto".
- ASN y tipo de red: centro de datos frente a proveedor residencial. Consulte bases como GeoIP2, IPinfo o IP2Proxy.
- Protocolos y pila: ausencia de IPv6, TTL anómalo, opciones TCP raras — en una red móvil real suelen ser más estables.
- Huella TLS: desajuste entre el JA3 del navegador y el agente de usuario declarado; un buen motivo para sospechar. Lea sobre JA3.
- Comportamiento DNS: resolución a través de resolutores públicos "de" otra región o tiempos no estándar.
- Zona horaria e idioma: Accept-Language y la hora local no coinciden con la ciudad declarada.
- WebRTC: los candidatos ICE a menudo delatan la interfaz real. La documentación del API está en MDN.
- Anycast y CGNAT: concentraciones de clientes "en" una misma IP confunden los modelos — prepare reglas sobre densidad/entropía.
La práctica es simple: combinamos señales en una tarjeta de puntuación, donde "centro de datos + User-Agent móvil + JA3 inusual" pesa más que "IP extraña, pero lo demás es normal".
GPS y triangulación por Wi‑Fi: cuando la física ayuda
El GPS por sí solo no es la panacea: en Android se puede "emular" la ubicación, y en el navegador el usuario puede negar el permiso. Pero si se combinan GPS, escaneo de Wi‑Fi, torres móviles y sensores inerciales, el cuadro resulta más convincente. Además, la triangulación por Wi‑Fi suele ser más precisa en ciudad.
- Cruzar fuentes: país por IP, coordenadas GPS, BSSID de Wi‑Fi alrededor, CellID. Una desviación mayor a la permitida es un disparador para una verificación adicional.
- Velocidad de desplazamiento: un "salto" de 3000 km en un minuto resulta épico, pero perjudica la confianza.
- Altímetro y satélites: un GPS real ofrece altitud y número de satélites; una ubicación simulada no o lo "dibuja" demasiado uniforme.
- Catálogos Wi‑Fi: coteje BSSID con fuentes abiertas como Mozilla Location Service (respetando la privacidad y los términos del servicio).
Una aproximación de "discrepancia leve": no bloquear, sino solicitar una verificación. Por ejemplo, pedir que active la geolocalización, completar un mini‑reto o confirmar la dirección en el siguiente ingreso de fondos.
Emuladores y VDI: lisos en la captura de pantalla, ruidosos en la telemetría
Los emuladores son habituales en esquemas de cuentas masivas. Allí es fácil cambiar el IMEI, el modelo o el idioma. Pero el emulador genera un conjunto de artefactos: sensores ausentes, renderizador gráfico como SwiftShader, batería extraña, proporciones de ancho/alto idénticas, cámaras "muertas".
- Play Integrity: en Android utilice el Play Integrity API como reemplazo de SafetyNet. Es la base para el estatus "attested" del dispositivo.
- App Attest / DeviceCheck: para iOS — DeviceCheck y App Attest.
- Heurísticas: propiedades ro/propiedad de Android (ro.kernel.qemu), ABI poco comunes, sensores vacíos, huellas de bibliotecas de emulador, renderizador GPU, build fingerprint idénticos, números de serie repetidos.
- VDI/entornos corporativos: Citrix/VMware muestran controladores de pantalla característicos y módulos de redirección. Consulte información sobre productos de Citrix y VMware Horizon para saber qué buscar.
En el navegador también se detecta VDI/VM: Canvas/WebGL atípico, elevada variabilidad de temporizadores, fuentes estables independientemente de la localidad. La buena noticia: todo esto contribuye muy bien a un perfil del dispositivo.
Huella del dispositivo: Canvas/WebGL, fuentes, temporizaciones
Los navegadores antidetector intentan falsificar cada capa. Pero cuando se acumulan decenas de señales independientes, resulta difícil construir un mosaico creíble. Los vectores tradicionales son Canvas/WebGL, AudioContext, conjunto de fuentes, métricas de entrada, latencias de eventos, duración de frames de animación, inestabilidades del High‑Resolution Time.
- Multicapa: 1–2 señales son fáciles de falsificar; 40+ ya no. Extraiga el perfil de renderizado y de tiempos de respuesta de la interfaz.
- Dinámica: no solo "qué" aparece, sino "cómo" cambia con el tiempo. Telemetría lineal como una regla es sospechosa.
- Soluciones comerciales y de código abierto: observe opciones como Fingerprint o FingerprintJS como punto de partida.
Arquitectura antifraude: reglas más ML
El punto óptimo es la combinación de reglas deterministas y un modelo que entienda el contexto. Las reglas atrapan violaciones claras; el modelo captura combinaciones complejas. Toda hipótesis se valida con A/B y debe impactar métricas de negocio, no solo las impresiones del equipo.
- Recolección de telemetría: IP/ASN, huellas TLS, WebRTC, Canvas/WebGL, GPS/Wi‑Fi/CellID, sensores.
- Normalización: esquemas de registro iguales en web y móvil.
- Reglas: "centro de datos + UA móvil" o "salto de 1000 km en 5 minutos".
- ML: señales sobre el grafo de relaciones entre dispositivos/cuentas. Para grafos es útil, por ejemplo, Neo4j.
- Comprobaciones: retos suaves en lugar de bloqueos rígidos.
Casos prácticos
Para no sonar como un manual, algunos patrones "reales".
- Granja de proxies móviles: la IP aparenta ser móvil, pero la huella TLS es tipo headless, WebRTC revela una subred interna, el entorno Wi‑Fi es "nulo". Solución: puntuación combinada + retos GPS selectivos.
- VDI en centro de llamadas: ciudad "Moscú", pero Canvas idéntico en cientos de sesiones y el controlador de vídeo es "virtual". Solución: perfilado de firmas VDI + límites en operaciones de riesgo.
- Abuso con emulador: Play Integrity falla, sensores vacíos, batería estática. Solución: suspensión de bonos/pagos hasta pasar verificaciones adicionales.
Plan paso a paso de implementación
La estrategia de "no todo a la vez, sino por capas" suele ganar.
- Filtros rápidos: IP de centro de datos, VPN/proxy evidente, conflicto entre idioma y zona horaria.
- Huella del navegador y verificación JA3 con el User‑Agent.
- Verificación geo: IP contra GPS/Wi‑Fi; anomalías de velocidad.
- Atestación móvil: Play Integrity / App Attest; comprobaciones básicas anti‑emulador.
- Grafo de dispositivos/cuentas: IP compartidas, cookies/tokens, hardware, comportamiento.
- Retos según riesgo: selectivos y respetuosos con la experiencia de usuario.
Tabla: señal, riesgo, cómo intentan evadir y cómo reducir falsos positivos
| Señal | Qué indica | Cómo intentan evadirla | Cómo reducir falsos positivos |
|---|---|---|---|
| ASN de centro de datos | VPN/proxy | Proxies móviles | Combinar con JA3 y WebRTC |
| JA3 no coincide con UA | Suplantación del cliente | Ajustes finos del antidetector | Umbral por acumulación de señales |
| Conflicto GPS vs IP | Suplantación de ubicación | Ubicación simulada | Triangulación Wi‑Fi y velocidad de desplazamiento |
| Sensores vacíos | Emulador | Inyección de ruido aleatorio | Análisis de dinámica y App Attest/Integrity |
| Controlador de vídeo virtual | VDI/VM | Cambio de agente | Firmas VDI + perfil Canvas/WebGL |
| WebRTC ICE muestra interfaz "ajena" | Proxy/túnel | Desactivar WebRTC | Degradación gradual: dar más peso a otras señales |
Privacidad y ley: dónde están los límites
Incluso la mejor solución antifraude se desmorona sin un manejo correcto de los datos personales. Los permisos de geolocalización deben pedirse solo cuando proceda y con una explicación clara. Los BSSID y otros identificadores deben almacenarse en forma hasheada y por un tiempo limitado. Familiarícese con los requisitos del GDPR y responda con rapidez a las solicitudes de los usuarios sobre sus datos.
Métricas de éxito: no "atrapar a todos", sino "rentabilizar la inversión"
No mida solo "cuánto se atrapó", sino qué daño se evitó y a qué coste. Observe retención, rechazos falsos, la proporción de tráfico "honesto" que pasa sin fricción. Y sí, cualquier nueva heurística debe someterse a A/B testing, de lo contrario es fácil afectar a usuarios legítimos.
Herramientas y enlaces para empezar
- MaxMind GeoIP2 y IPinfo para inteligencia de IP.
- IP2Proxy para clasificar VPN/proxy.
- Google Play Integrity API, Apple DeviceCheck y App Attest para la atestación de dispositivos.
- JA3 como punto de partida para huellas TLS.
- Documentación WebRTC para analizar candidatos ICE.
- Mozilla Location Service para triangulación por Wi‑Fi.
- Fingerprint y FingerprintJS para huella de navegador.
Conclusión
La suplantación de ubicación, VPN/proxy, emuladores y VDI no son "magia", sino un conjunto de señales mal sincronizadas. Si se escucha la red, el dispositivo y el comportamiento al mismo tiempo, el panorama aparece con rapidez. Apunte a la multicapa: nivel IP, GPS/Wi‑Fi, huella del dispositivo y atestación. Añada retos claros según el riesgo y respeto por la privacidad — y el geofraude dejará de ser un dolor de cabeza para convertirse en una métrica manejable.
