This chapter covers geolocation analysis in threat hunting, a key technique for identifying anomalous access patterns and detecting credential theft, insider threats, and targeted attacks. For the CS0-003 exam, geolocation analysis appears in roughly 5-8% of questions, often combined with log analysis and threat intelligence. Mastering this topic requires understanding how IP-to-location mapping works, its limitations, and how to use it effectively in a security operations center (SOC) environment.
Jump to a section
Imagine a detective investigating a series of bank robberies. The detective doesn't just look at security footage; she overlays each robbery's timestamp and location onto a digital map of the city. As she adds more pins, a pattern emerges: the robberies occur along a specific bus route, and the times suggest the suspect catches the 8:15 AM bus from the east side to downtown. The detective then pulls cell tower records to confirm the suspect's phone connected to towers along that route at those times. In threat hunting, geolocation analysis works similarly. A security analyst collects IP addresses from log entries—firewall logs, VPN logs, cloud access logs—and uses a geolocation database (like MaxMind GeoIP) to map each IP to a physical location (country, city, latitude/longitude). The analyst then plots these locations on a timeline. Just as the detective looks for clusters and routes, the analyst looks for impossible travel—e.g., a user logging in from New York and then from London within 30 minutes—which indicates credential misuse or a VPN/proxy bypass. The analyst also checks for known malicious IP ranges from specific regions (like Russia or North Korea) or for traffic originating from data centers (indicating botnets or cloud-based attacks) versus residential IPs. The geolocation database is like the detective's city map—it's not perfect, but it provides critical context for connecting the dots. The analyst must also account for IP spoofing, VPNs, and Tor, which are like the robber using a disguise or a different bus—the location data might be misleading, so the analyst must cross-reference with other indicators like user-agent strings, browser fingerprints, and authentication methods.
What Is Geolocation Analysis and Why Does It Exist?
Geolocation analysis is the process of determining the physical location of an IP address or other network identifier (e.g., MAC address, Wi-Fi access point) and using that information to enrich security events. In threat hunting, it helps answer questions like: "Is this login from a country where we have no business?" or "Can a user physically be in two distant cities within an hour?" The primary reason geolocation analysis exists is to provide context. Raw IP addresses are meaningless without context; geolocation adds a geographic dimension that can flag anomalies. For example, a login from a known malicious IP range in Eastern Europe is more suspicious than one from a domestic residential ISP. Geolocation is also used to enforce geo-blocking—denying access from high-risk countries—and to detect VPN/proxy usage when the reported location differs from the expected one.
How Geolocation Works Internally
Geolocation is not a single protocol; it's a data lookup service. The most common source is the Internet Assigned Numbers Authority (IANA) and Regional Internet Registries (RIRs) like ARIN, RIPE, APNIC, LACNIC, and AFRINIC, which assign IP blocks to organizations and ISPs. Commercial databases like MaxMind GeoIP2 and IP2Location combine RIR data with partner data (ISP subscriber information, Wi-Fi positioning, GPS data from mobile devices) to build a mapping of IP ranges to geographic coordinates, cities, postal codes, and even time zones. When a security tool (SIEM, firewall, threat hunting platform) receives a log entry with an IP address, it sends a lookup request to the geolocation database (often via an API or local file). The database returns a record with fields such as: - continent, country, region, city, postal code - latitude and longitude - time zone - ISP or organization name - connection type (e.g., residential, business, hosting, education) - threat level (if available)
The tool then enriches the log entry with these fields, allowing analysts to filter, search, and visualize by geography.
Key Components, Values, Defaults, and Timers
Geolocation Database Accuracy: Depends on the provider. MaxMind GeoIP2 City database claims 99.8% accuracy at the country level, but only ~60-80% at the city level for many regions. The database is updated monthly; stale data can cause false positives.
IP Address Types: Public IPs are routable and can be geolocated. Private IPs (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local (169.254.0.0/16) have no geographic meaning and should be excluded.
VPN and Proxy Detection: Some databases include a flag indicating whether an IP is a known VPN endpoint, proxy, or Tor exit node. This is crucial for threat hunting because a user connecting from a VPN may appear to be in a different country.
Geofencing: The practice of allowing or blocking traffic based on geolocation. Default policies often block all countries except those where the organization operates.
Timers: No standard timers, but lookups are typically cached for performance. In a SIEM, cache TTL is often 24 hours. Stale cache entries can cause incorrect geolocation.
Configuration and Verification Commands
MaxMind GeoIP Update: The geoipupdate command downloads the latest database. Example:
geoipupdate -v -f /etc/GeoIP.confLookup Tool: geoiplookup to query a local GeoIP database:
geoiplookup 8.8.8.8Output:
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, CA, Mountain View, 37.386001, -122.113800, 94043, 807, 0SIEM Query Example (Splunk):
index=main sourcetype=access_combined | iplocation clientip | where Country="Russia"Firewall Policy (pfSense): Under Firewall > Rules, create a rule with source or destination set to a GeoIP alias (e.g., "Block_Russia").
Interaction with Related Technologies
Geolocation analysis is often combined with: - User and Entity Behavior Analytics (UEBA): UEBA platforms use geolocation as one of many features to build a baseline of normal user behavior. A sudden login from a new country triggers an anomaly score increase. - Threat Intelligence Feeds: IP addresses from threat intel (e.g., AlienVault OTX, MISP) are often tagged with country of origin. Correlating geolocation with threat intel can help prioritize alerts. - Authentication Logs: Failed login attempts from unusual geolocations may indicate password spraying attacks. Successful logins from unexpected locations may indicate compromised credentials. - Cloud Access Logs: AWS CloudTrail, Azure Activity Log, and GCP Audit Logs include source IP addresses. Geolocation analysis can detect if an API call originated from an unexpected region, especially when using cloud resources. - DNS Logs: DNS queries can be geolocated to detect domain generation algorithm (DGA) traffic or command-and-control (C2) communications with known malicious IP ranges.
Limitations and Pitfalls
IP Spoofing: Attackers can spoof source IP addresses, but spoofed packets rarely complete a TCP handshake, so geolocation of spoofed addresses is irrelevant for connection-based logs.
VPNs and Proxies: Legitimate users often use VPNs for privacy. A login from a VPN IP may appear as a different country, causing false positives. Analysts must check the connection type field.
Mobile Devices: Cellular IPs are often geolocated to the ISP's gateway location, not the user's actual location. For example, a user in New York may appear to be in New Jersey because the ISP's POP is there.
Database Inaccuracy: IP blocks change ownership, and databases may be outdated. Always verify with multiple sources if critical.
IPv6: Geolocation for IPv6 is less accurate because IPv6 addresses are often assigned dynamically from large blocks.
Exam-Relevant Details
The CS0-003 exam expects you to know that geolocation data is derived from IP address registration and not from the packet itself. Understand that geolocation is an enrichment, not a definitive source of truth.
Be aware of the concept of "impossible travel" — a user cannot log in from two distant locations within a time shorter than travel time. The exam may present logs with timestamps and IP geolocations and ask you to identify the anomaly.
Know that geolocation can be used for geo-blocking as a security control, but it is not foolproof and can be bypassed by VPNs.
Understand that geolocation data is often used in combination with other indicators like user-agent strings, browser fingerprints, and authentication methods to build a more complete picture.
Collect IP Addresses from Logs
Start by gathering raw log data from various sources: firewall logs, VPN logs, web server logs, cloud audit logs, and authentication logs. Extract all source IP addresses. In a SIEM, this is done via a search query (e.g., `index=main | fields src_ip`). Ensure you capture the timestamp of each event. For the exam, you'll often see a table of logs with timestamps and IP addresses. Pay attention to the timezone — logs are often in UTC. Also note that private IPs (RFC 1918) should be filtered out as they have no geographic meaning. If the log contains both source and destination IPs, focus on the source IP for user activity.
Enrich IPs with Geolocation Data
Perform a geolocation lookup for each public IP address. In a SIEM, this is done using a command like `iplocation` in Splunk or a lookup table in Elasticsearch. The lookup returns country, city, latitude, longitude, ISP, and connection type. For example, the IP 8.8.8.8 resolves to Mountain View, California, USA, ISP: Google. The enrichment adds context: a login from a Russian IP is more suspicious if the user normally logs in from the US. The exam may give you a list of IPs and ask you to identify which ones are from high-risk countries. Remember that geolocation databases may have errors, especially at the city level. Always verify with multiple sources if possible.
Plot Locations on a Timeline
Create a timeline of events, mapping each event's geolocation to a timestamp. This can be done manually or with visualization tools like Kibana's coordinate map or a custom Python script. The goal is to spot impossible travel: if a user logs in from New York at 10:00 UTC and from London at 10:30 UTC, that's physically impossible (flight time > 6 hours). The exam will present such scenarios. Also look for clusters of activity from the same location over a short period — this could indicate a brute-force attack. Conversely, a single login from a distant location might be a sign of credential theft. When plotting, consider the user's baseline: a frequent traveler may have legitimate logins from multiple countries.
Correlate with Other Indicators
Geolocation alone is not conclusive. Cross-reference with other data: user-agent strings, browser fingerprints, authentication method (e.g., MFA vs. password-only), and device information. For example, a login from a Russian IP with a user-agent string of a recent Chrome version and valid MFA might be a legitimate user using a VPN. Without MFA, it's more suspicious. Also check if the IP is known to be a VPN endpoint or proxy (many geolocation databases include this flag). The exam may provide a log entry with multiple fields; you must decide whether the geolocation anomaly is likely malicious or benign based on the context. Always ask: "Is there a plausible explanation?"
Generate Alerts and Investigate
Based on the analysis, generate alerts for true anomalies. Common alert rules: login from a country not in the user's travel history, impossible travel, login from a known malicious geolocation (e.g., IP ranges associated with APT groups), or access from a data center IP when the user normally uses a residential ISP. The investigation should include checking the user's recent activity, contacting the user, and reviewing additional logs. In the exam, you may be asked to recommend a response: block the IP, disable the account, or require MFA re-authentication. Always consider the business impact — blocking a country might affect legitimate customers. Document findings and update threat intelligence feeds if the IP is confirmed malicious.
Scenario 1: Detecting Credential Theft in a Global Enterprise A multinational corporation with offices in New York, London, and Tokyo uses a centralized Active Directory. Users authenticate via VPN. The SOC deploys a SIEM that enriches VPN logs with geolocation. One morning, an alert fires: a user based in New York logs in from an IP geolocated to Lagos, Nigeria, at 3:00 AM UTC, followed by a successful login from New York at 3:15 AM UTC — impossible travel. The analyst checks the user's recent activity: the user had not traveled, and the Lagos login used a valid password but no MFA (MFA was not enforced for VPN). The analyst immediately disables the account and initiates password reset. Further investigation reveals the user had clicked a phishing link the previous day. The geolocation analysis was crucial in detecting the breach early. In production, the SIEM is configured with a rule that triggers on any login from a country not in the user's profile, with a severity based on the user's role. The geolocation database is updated weekly, and the cache TTL is set to 12 hours to balance performance and accuracy.
Scenario 2: Geo-Blocking to Prevent Automated Attacks A financial services company experiences frequent brute-force attacks on its customer-facing web application. The attacks originate from IP ranges in Eastern Europe and Asia. The company implements geo-blocking at the web application firewall (WAF) level: all traffic from countries outside North America and Western Europe is blocked, except for a few known partner IPs. This reduces attack volume by 90%. However, legitimate customers traveling abroad are blocked. To mitigate, the company maintains an allowlist of IPs for known travelers and uses a geolocation database that includes connection type (e.g., residential vs. hosting) to allow residential IPs from blocked countries if they match a customer's known travel pattern. The WAF logs are enriched with geolocation for monitoring. Misconfiguration occurs when the geolocation database incorrectly maps a domestic IP to a foreign country, causing false blocks. The company resolves this by using multiple geolocation sources and manually verifying critical IPs.
Scenario 3: Insider Threat Detection A tech company monitors access to its source code repository. An employee in the US accesses the repo from an IP geolocated to a data center in Germany. The employee has no business reason to be in Germany. The analyst checks the IP's connection type: it's a cloud hosting provider. The user-agent string matches the employee's usual browser, but the authentication method is a personal access token, not the usual SSO. The analyst contacts the employee, who admits to sharing the token with a contractor abroad. This is a policy violation. The geolocation analysis flagged the anomaly because the access pattern deviated from the employee's baseline. In production, the company uses UEBA that incorporates geolocation as a feature. The system learns that the employee usually accesses from the US, so a German IP increases the anomaly score. The threshold for alerting is set at 3 standard deviations above the mean. Performance considerations include the latency of geolocation lookups; the UEBA caches results per IP for 24 hours.
What CS0-003 Tests on Geolocation Analysis (Objective 1.1: Given a scenario, apply appropriate threat hunting techniques) The exam expects you to:
Understand that geolocation data comes from IP address registration and is used to enrich logs.
Recognize impossible travel scenarios based on timestamps and geolocation.
Identify when geolocation can be misleading (VPNs, proxies, mobile IPs, database inaccuracies).
Know how to use geolocation in threat hunting: filtering logs by country, detecting access from high-risk regions, and correlating with other indicators.
Be able to interpret a log entry with geolocation fields and determine if it's anomalous.
Common Wrong Answers and Why Candidates Choose Them 1. Assuming geolocation is always accurate at the city level. Many candidates think that if a geolocation database says a city, it's exact. The exam tests that city-level accuracy is much lower (60-80%). A question might show a log with a city and ask if it's suspicious; the correct answer often is that city data is unreliable, so focus on country or region. 2. Confusing source IP geolocation with destination IP geolocation. In a log, the source IP is the client's IP, and the destination IP is the server's. Candidates sometimes look at the wrong IP. The exam will have both fields; you must know which one to analyze for user location. 3. Ignoring the possibility of VPNs or proxies. A candidate might flag a login from another country as malicious, but if the user is known to use a VPN, it could be benign. The exam expects you to check the connection type field or user profile. 4. Overlooking time zones. Logs are often in UTC. Candidates might compare timestamps without converting to local time, leading to false impossible travel conclusions. The exam may include a time zone conversion step.
Specific Numbers and Terms That Appear on the Exam - Impossible travel: defined as two logins from locations more than 500 miles apart within less than 1 hour (roughly, but not exact). The exam may give specific distances and times. - Geo-blocking: a security control that blocks traffic from specific countries. - MaxMind GeoIP: the most commonly referenced geolocation database in exam questions. - Connection types: residential, business, hosting (data center), education, mobile. - RIRs: ARIN (North America), RIPE (Europe), APNIC (Asia Pacific), LACNIC (Latin America), AFRINIC (Africa).
Edge Cases and Exceptions - IPv6: Geolocation for IPv6 is less reliable; the exam may note that IPv6 addresses are often from large blocks and may map to a region rather than a city. - CDN and Cloud Front: IP addresses from CDNs (e.g., Cloudflare) may geolocate to the CDN's edge location, not the actual user. The exam may present a log where the IP is from a CDN, and you must recognize that the user's real location is masked. - Satellite Internet: IPs from satellite ISPs may geolocate to the ground station, not the user's physical location.
How to Eliminate Wrong Answers - If a question asks whether a login is suspicious, first check if the geolocation is consistent with the user's known travel history or VPN usage. If the user has no history, flag it but consider the connection type. - For impossible travel, calculate the time difference and distance. If physically possible (e.g., 2 hours between New York and Boston), it's not impossible travel. - If the geolocation database shows a data center IP, it could be a VPN or cloud attack. Cross-reference with the user's usual IP range. - Always read all answer choices; sometimes the correct answer is that geolocation data is insufficient and more context is needed.
Geolocation analysis enriches IP addresses with geographic data from RIRs and third-party databases like MaxMind.
Impossible travel detection relies on comparing timestamps and distances between login locations.
City-level geolocation accuracy is ~60-80%; country-level is >99%.
Always consider VPNs, proxies, mobile IPs, and CDNs when interpreting geolocation data.
Geolocation is one piece of the puzzle; correlate with user-agent, authentication method, and user profile.
Geo-blocking is a common security control but can cause false blocks for legitimate users.
The CS0-003 exam may present logs with IPs and timestamps; you must identify impossible travel or suspicious geolocations.
IPv6 geolocation is less reliable than IPv4 due to larger address blocks and dynamic assignment.
These come up on the exam all the time. Here's how to tell them apart.
Geolocation Analysis
Determines physical location (country, city) of an IP address.
Uses registration data and partner data from ISPs.
Useful for detecting impossible travel and geo-blocking.
Can be bypassed by VPNs and proxies.
City-level accuracy is often low.
IP Reputation Analysis
Assesses whether an IP address is known for malicious activity (spam, malware, C2).
Uses threat intelligence feeds, blacklists, and historical data.
Useful for blocking known bad actors regardless of location.
Can be evaded by attackers using new or clean IPs.
Provides a binary or score of maliciousness.
Mistake
Geolocation data comes from the IP packet itself.
Correct
Geolocation is derived from IP address registration databases (RIRs) and third-party data, not from the packet. The packet only contains the IP address; the location is looked up externally.
Mistake
Geolocation is always accurate to the city level.
Correct
City-level accuracy varies widely, often 60-80% for many regions. Country-level accuracy is much higher (>99%). The exam expects you to treat city data as approximate.
Mistake
A login from a foreign country always indicates a compromise.
Correct
Users may travel, use VPNs, or have remote workers abroad. Always check the connection type (VPN, residential) and user profile before concluding malicious activity.
Mistake
Impossible travel means the user logged in from two different countries within 24 hours.
Correct
Impossible travel specifically means the time between logins is less than the minimum travel time between the two locations. For example, New York to London in 1 hour is impossible, but over 8 hours is possible.
Mistake
Geolocation can detect the exact physical address of a user.
Correct
Geolocation databases typically provide city or postal code level, not street address. Accuracy at the street level is rare and unreliable. The exam treats geolocation as regional, not precise.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Geolocation analysis works by taking IP addresses from logs (firewall, VPN, web server, etc.) and looking up their geographic location using a database like MaxMind GeoIP. The database maps IP ranges to countries, cities, coordinates, ISPs, and connection types. Analysts then use this enriched data to identify anomalies such as logins from unexpected countries, impossible travel (two logins far apart in a short time), or access from known malicious regions. The key is to combine geolocation with other indicators (user-agent, MFA status) to reduce false positives.
Impossible travel is a scenario where a user logs in from two geographically distant locations within a time frame that is physically impossible to travel between. For example, a login from New York at 10:00 UTC and then from London at 10:30 UTC is impossible because the flight takes over 6 hours. Detection involves comparing the timestamps and geolocations of consecutive logins for the same user. If the time difference is less than the minimum travel time (calculated using great-circle distance and typical travel speeds), it triggers an alert. The exam may ask you to identify impossible travel from a set of log entries.
Yes. Attackers can use VPNs, proxies, or Tor to mask their true location. When a user connects through a VPN, the IP address seen by the target server belongs to the VPN provider, which may be in a different country. Similarly, proxies and Tor exit nodes obscure the origin. Therefore, geolocation analysis should not be the sole factor for decision-making. Always check the connection type field in the geolocation database (e.g., 'hosting' indicates a VPN/data center) and look for other anomalies like unusual user-agent strings or lack of MFA.
Limitations include: city-level inaccuracy (60-80% accurate), stale data (IP blocks change ownership), mobile IPs mapping to ISP gateways not user location, IPv6 less reliable, and CDN IPs masking user location. Additionally, some databases may misidentify the country of certain IPs. The exam expects you to understand these limitations and not rely solely on geolocation for critical decisions.
SIEM platforms have built-in geolocation enrichment capabilities. For example, Splunk uses the `iplocation` command to add fields like Country, City, lat, lon to events. Elasticsearch uses the `geoip` processor in Logstash or the `geoip` enrichment policy. The enriched data can be used in dashboards, alerts, and searches. A common use case is creating an alert for any login from a country not in a user's travel history. The SIEM caches geolocation results to improve performance, with a default TTL of 24 hours.
Geo-blocking is a security control that blocks traffic from specific countries or regions based on geolocation. It is implemented at firewalls, WAFs, or reverse proxies. For example, a company may block all traffic from countries where it has no business operations. Implementation involves creating access control lists (ACLs) or rules that use geolocation objects (e.g., country codes). The rule denies traffic if the source IP's country matches a blocked list. Geo-blocking can reduce attack surface but may also block legitimate users (e.g., traveling employees). An allowlist is often used to override blocks for known IPs.
Insider threats often involve abnormal access patterns. For example, an employee accessing sensitive data from an unusual location (e.g., a data center IP when they normally use a home ISP) could indicate credential sharing or malicious intent. Geolocation analysis combined with UEBA can detect such deviations. The system builds a baseline of a user's typical login locations (e.g., city, country, ISP). When a login occurs from a new location, especially a high-risk one, an alert is generated. The analyst then investigates the context (time, data accessed, authentication method) to determine if it's malicious.
You've just covered Geolocation Analysis in Threat Hunting — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?