Impossible Travel Detection: Building a Geospatial UEBA Model
How DKTrace's ml-engine calculates whether a login sequence is physically possible using Haversine distance, timestamps, and realistic travel speeds — including VPN, CDN, and NAT gateway edge cases.
DKTrace Research Team
Security Engineering · Threat Research
The Problem
Impossible Travel is simple in principle: if User A logs in from London at 09:00 and from Lagos at 09:47, they cannot have physically travelled there.
In production SOC environments, naive implementations generate enormous false-positive volumes from:
DKTrace's Approach
The ml-engine maintains a geo-velocity profile for every entity:
The Algorithm
def check_impossible_travel(login_event):
prev = get_last_login(login_event.user_id)
if not prev:
return # No baseline yet
distance_km = haversine(
prev.latitude, prev.longitude,
login_event.latitude, login_event.longitude
)
time_hours = (login_event.timestamp - prev.timestamp).total_seconds() / 3600
if time_hours < 0.01: # same-second logins = shared session token
return
speed_kmh = distance_km / time_hours
if speed_kmh > 900: # commercial aircraft max
if (login_event.src_ip not in vpn_ranges and
login_event.src_ip not in cdn_ranges and
login_event.src_ip not in cloud_nat_ranges):
risk_delta = min(40, speed_kmh / 25)
ueba_score_update(login_event.user_id, risk_delta)
fire_alert("T1078", confidence="HIGH", speed_kmh=speed_kmh)False Positive Suppression Rules
DKTrace suppresses the alert when any of these apply:
Production Results (Banking Deployment)
Over 90 days:
See It Live
Watch DKTrace detect this threat in your environment
Our engineers will run a live detection simulation against a sample of your log telemetry — no agents, no commitment.
Request a Live Demo