A SOC analyst escalates a login surge from what the SIEM labels as São Paulo. The geo feed is confident. The ASN belongs to a regional ISP. Thirty minutes later, packet timing, reverse DNS, and a second commercial lookup place the same addresses in a Miami colo used by a Brazilian hosting reseller. The city field never lied in a technical sense. It answered a different question than the one the playbook assumed.
That gap matters more in 2026 as campaigns such as Mirage Kitten targeting aviation and FinTech across the Middle East and Africa, ValleyRAT adware fronts, and SEO abuse that routed Brazilian government sites into foreign-operated traffic show how infrastructure location and operator location routinely diverge. Geolocation remains useful. Treating city fields as ground truth is where investigations stall.
What accuracy actually means in operations
IP geolocation maps an address to a place derived from registry data, routing announcements, commercial probes, and provider self-reporting. Country-level results for wired broadband and many enterprise ranges often hold for triage. City and coordinates degrade quickly when the address sits on shared infrastructure.
Accuracy collapses in predictable places:
- Carrier-grade NAT pools that serve wide regions from a few egress blocks
- Cloud and VPS regions where the billed region and the physical POP differ
- CDN and reverse-proxy edges that terminate sessions far from the origin operator
- Mobile roaming and enterprise VPN egress that overwrite the user’s true network path
- Stale MaxMind-style or registry snapshots that lag renumbering by weeks
For cybersecurity work, the operational question is not “which city string is printed.” It is “how much decision weight can this field carry before a second signal confirms or vetoes it.”
A short scenario from the wire
Consider a credential stuffing wave against a FinTech customer portal. Alerts fire on Brazil as the dominant country tag. Geo-blocking advocates on the team want an immediate deny for that country. Cross-checks show many source IPs resolve to ASNs announced for cloud providers with Brazilian customer bases and U.S. or European POPs. Latency from your edge to those IPs matches East Coast U.S. round trips, not São Paulo. Blocking “Brazil” would have clipped legitimate corporate VPN users while leaving the stuffing traffic on cloud exits untouched.
Parallel noise shows up in malware reporting. ValleyRAT samples distributed through adware-style installers often ride shared hosting and CDN fronts. City stamps on download IPs describe the delivery network, not the operator desk. The same pattern appears when foreign actors abuse compromised Brazilian government properties for SEO weaponization. The geo of the compromised site and the geo of the controlling infrastructure answer separate investigative questions.
Detection steps that test the geo claim
Build a verification pass into every high-impact geo-driven alert. Keep it short enough for on-call use.
1. Resolve the address class before you trust the city
Classify each source IP as residential broadband, mobile carrier, enterprise, cloud/VPS, CDN edge, or anonymizing proxy. Your SIEM should store that class beside country and city. City confidence for cloud and CDN classes should default low. Country confidence can stay usable for routing decisions that already account for shared hosting.
2. Cross-check at least two independent geo sources
Query two commercial or open databases plus the RIR WHOIS and current BGP announcement. Record disagreements explicitly. A country mismatch across providers is a stop sign for automated geo-blocks. A city mismatch with a shared country is normal for CGNAT and cloud ranges and should lower severity, not raise it.
3. Add path evidence the database cannot invent
Capture reverse DNS, TLS JA3/JA4 or HTTP client fingerprints where available, round-trip timing from your edge, and prior reputation for the /24. Latency that contradicts the claimed continent is stronger than a database city. Mirage Kitten-style targeting of MEA aviation and FinTech often involves infrastructure that looks regional in marketing copy while resolving through unrelated hosting footprints. Path evidence keeps attribution honest.
4. Score confidence instead of printing a single location
Write a simple ordinal score into the alert:
- Country agreed by two databases and ASN registry
- City agreed by two databases and consistent with latency band
- Hosting or CDN class overrides city regardless of vendor confidence
- Any disagreement freezes auto-response and forces analyst review
Teams that already lean on AI alert filtering, including approaches highlighted by Recorded Future’s AI filtering launch, get better results when geo confidence is a first-class feature rather than a free-text city string the model treats as fact.
5. Watch for abuse patterns that exploit geo trust
Flag bursts where many “cities” share one ASN and one /24. Flag authentication events whose geo jumps continents inside a session lifetime that is shorter than real travel. Flag blocklist hits whose only enrichment is a high-confidence city with no ASN or hosting class. Those patterns show up in stuffing, adware C2 staging, and SEO abuse that hops through compromised regional sites.
Response actions once accuracy is in doubt
When geo confidence drops, change the control, not only the ticket text.
- Scope blocks by ASN and hosting class first. Prefer temporary denies on cloud ASNs showing stuffing volume over country-wide geo denials built from weak city data.
- Keep country blocks for coarse risk reduction only. Use them for services with no legitimate regional audience and pair them with allowlists for known corporate egress.
- Enrich incident timelines with dual locations. Store “database geo” and “inferred path geo” as separate fields so postmortems stay coherent when vendors disagree.
- Retune playbooks after H1 malware and vulnerability trend reviews. Campaign reporting that names regions often describes victim sector and lure language. Map those claims to victim telemetry, not to the city of the first malicious IP you observed.
- Feed corrected labels back into detection. If Miami colo traffic was labeled São Paulo for three weeks, update the entity cache and suppress repeat false regional narratives for that prefix.
Implementation details that hold up on a busy desk
In the logging pipeline, attach geo_country, geo_city, geo_confidence, ip_class, asn, and geo_source on every authentication, WAF, and VPN event. Reject automation that keys solely on city. For VPN and zero-trust gateways, compare claimed client geo against the tunnel egress geo and raise a medium alert on continent mismatch without immediate lockout.
For threat intel ingestion, strip city fields from shared indicators unless the provider documents the method and date of the fix. Prefer ASN, network range, and malware family tags. When FBI-scale identity theft investigations and large credential dumps drive opportunistic stuffing, attackers buy access to residential proxies and cloud ranges faster than geo databases refresh. Your response speed depends on class and ASN more than on municipal labels.
Quarterly, sample 100 alerted IPs and compare vendor city, measured latency band, and ASN type. Publish the agreement rate to leadership. That metric tells you whether geo-driven controls are calibrated or decorative.
Practical takeaways
- Treat country as a coarse filter and city as a hypothesis that needs path confirmation.
- Classify cloud, CDN, mobile CGNAT, and residential ranges before any geo-based auto-block.
- Require dual-database agreement plus latency or ASN consistency for high-impact actions.
- Separate infrastructure location from actor location in every write-up involving regional campaigns.
- Measure your own geo error rate on live alerts so vendors and playbooks stay accountable.
IP geolocation earns its place in detection and response when teams score its confidence in public. The city field in your SIEM is a starting clue. The investigation finishes when routing, hosting class, and timing agree on a place you can defend in a postmortem.
