SOC · BGP · RPKI
How to analyse a suspicious IP address during an investigation
An unknown connection or traffic spike in logs is a starting point, not proof of intrusion. Analysing a suspicious IP address requires contextualising the observed infrastructure and correlating findings with events in your systems.
This guide explains how to use an IP address and ASN analyser to read WHOIS, examine BGP routing and interpret RPKI. Administrative geolocation alone is insufficient for a blocking decision.
1. Decode administrative allocation: WHOIS
The registered organisation
Regional Internet registries record IPv4 and IPv6 block allocations. RIPE NCC covers Europe, the Middle East and parts of Central Asia. The registered holder may be an operator, hosting provider or organisation; it is not necessarily the user of the address at the time of the incident.
The abuse contact
Look for a published abuse contact where available. Verify its scope and prepare a factual report with date, timezone, source and destination IPs, ports and relevant log excerpts. A missing contact may reflect source limitations rather than malicious intent.
Country and geolocation limits
Registry country is administrative information, not a certain location of the server or user. Cloud services, VPNs, proxies, NAT and shared addresses complicate attribution. Distinguish the block holder, service operator and actor behind the activity.
2. Analyse public routing: ASN and BGP
Identify the origin ASN and prefix
An autonomous system number (ASN) identifies a network with a routing policy. The origin ASN observed in BGP announces the prefix containing the IP. It does not by itself describe the actual path of your connection or identify the source machine.
Compare WHOIS and BGP without jumping to conclusions
A difference between registered holder and origin ASN can be legitimate: delegation, hosting, transit or customer announcements. An unexpected change warrants checking history, authorisations and other observations. A mismatch alone does not prove a prefix hijack.
Correlate with observed activity
A VPS or VPN IP is not evidence of an attack. Examine login attempts, frequency, ports, application responses and other IoCs. BGP visibility depends on collectors and measurement times; a route missing from one source may be visible elsewhere.
3. Interpret RPKI origin validation
ROAs authorise an ASN to originate certain prefixes. Origin validation compares the announcement with these authorisations; it does not validate the entire AS path or guarantee a legitimate connection.
Valid: authorised origin
At least one covering authorisation matches the origin ASN and permits the announced prefix length within maxLength. This validates route origin against available data, not the safety of the host or its traffic.
Invalid: incompatible origin or length
An authorisation covers the prefix, but none permits the observed origin/length combination. Misconfiguration or an unrecorded change may explain it, as may hijacking. Confirm the cause before attributing intent.
Not Found / Unknown: no covering authorisation
Validation finds no covering authorisation in the consulted data. This proves neither fraud nor safety. Distinguish it from an unavailable source or failed request, which does not establish the RPKI state.
4. Preserve usable point-in-time findings
RIPE IP’s “Copy JSON” button preserves the report, lookup timestamp and source status. Store it with original logs, timezone, IP, ports and alert context. Registry and routing data may have their own collection dates: a current lookup does not automatically reconstruct conditions at the time of a past incident.
Document missing information and the reasoning behind escalation or filtering. Assess effects on shared services before blocking an entire prefix or ASN. An IP and ASN lookup provides context, not certain attacker attribution.
Deploy SecurCheck Business to support your network administrators