How to Investigate an IP Address

Investigating an IP address is one of the most common tasks in security operations, incident response, and threat intelligence. An IP appears in your firewall logs, a phishing email header, a web server access log, or a threat intelligence alert. The next question is always the same: who is behind this IP, what are they running, and should you be concerned? This guide walks through a complete IP investigation using free, publicly available tools -- the same methodology used by SOC analysts and OSINT professionals.

Every technique described here is passive or semi-active. No port scanning, no vulnerability probing, no traffic that would alert the IP's operator. All data comes from public registries, APIs, and databases that anyone can query.

Step 1: Geolocation and Network Context

Start with the basics. Geolocating an IP address tells you the country, city (approximate), ISP, and autonomous system number (ASN). This immediately answers whether the IP belongs to a commercial ISP, a cloud provider, a hosting company, or a corporate network.

# Free geolocation API -- no key required (45 requests/minute)
curl -s "http://ip-api.com/json/93.184.216.34?fields=status,country,regionName,city,isp,org,as,query" | jq '.'

# Response:
# {
#   "status": "success",
#   "country": "United States",
#   "regionName": "Massachusetts",
#   "city": "Norwell",
#   "isp": "Edgecast Inc.",
#   "org": "Verizon Digital Media Services",
#   "as": "AS15133 Edgecast Inc.",
#   "query": "93.184.216.34"
# }

The ASN is particularly important. An IP belonging to AS15169 (Google) behaves differently from an IP on AS202425 (bulletproof hosting provider). Cloud provider IPs (AWS, Azure, GCP, DigitalOcean) are commonly used for both legitimate services and attack infrastructure. Residential ISP IPs may indicate compromised home devices (botnets) or VPN exit nodes.

Step 2: WHOIS and Registration Data

WHOIS reveals who is responsible for the IP block. Unlike domain WHOIS, IP WHOIS queries go to Regional Internet Registries (RIRs): ARIN (North America), RIPE NCC (Europe/Middle East), APNIC (Asia-Pacific), LACNIC (Latin America), and AFRINIC (Africa).

# WHOIS lookup for IP registration details
whois 93.184.216.34

# RIPE Stat API for structured data
curl -s "https://stat.ripe.net/data/whois/data.json?resource=93.184.216.34" | jq '.'

Key fields to examine: Organization name (who owns the IP block), CIDR range (how large is their allocation), abuse contact (where to report malicious activity), and creation/update dates (recently allocated blocks sometimes indicate new infrastructure).

Step 3: Reverse DNS

Reverse DNS (PTR records) maps an IP address back to a hostname. This reveals how the IP's operator has configured their infrastructure. A PTR record of mail.example.com tells you this IP runs a mail server. ec2-52-14-123-45.us-east-2.compute.amazonaws.com confirms it is an AWS instance.

# Reverse DNS lookup
dig -x 93.184.216.34 +short

# Alternative using host command
host 93.184.216.34

Missing PTR records are also informative. Legitimate mail servers require PTR records (email standards mandate it). An IP sending email without a PTR record is almost certainly spam or phishing infrastructure.

Step 4: Open Ports and Services

Without active scanning, you can check what services an IP exposes using databases that have already scanned it. Shodan InternetDB provides a free, no-authentication API that returns open ports, detected services, and known vulnerabilities for any IP.

# Shodan InternetDB -- free, no API key required
curl -s "https://internetdb.shodan.io/93.184.216.34" | jq '.'

# Response includes:
# - ports: [80, 443]
# - hostnames: ["example.com"]
# - vulns: ["CVE-2021-XXXXX"]
# - cpes: ["cpe:/a:apache:http_server:2.4.54"]

The combination of open ports tells a story. Port 22 (SSH) + 80 (HTTP) + 443 (HTTPS) is a standard web server. Port 25 (SMTP) + 110 (POP3) + 143 (IMAP) + 465/587 (SMTPS) is a mail server. Port 3389 (RDP) exposed to the internet is an immediate red flag -- exposed RDP is a primary ransomware entry vector, per the Verizon 2025 DBIR.

Step 5: Threat Intelligence Feeds

Check whether the IP appears in any threat intelligence databases. Multiple feeds should be checked because no single feed has complete coverage.

# AlienVault OTX -- comprehensive threat data
curl -s "https://otx.alienvault.com/api/v1/indicators/IPv4/93.184.216.34/general" | jq '{reputation: .reputation, pulse_count: .pulse_info.count}'

# AbuseIPDB -- community-reported abuse
curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=93.184.216.34" \
  -H "Key: YOUR_API_KEY" -H "Accept: application/json"

# ThreatFox -- malware IOCs
curl -s -X POST "https://threatfox-api.abuse.ch/api/v1/" \
  -d '{"query": "search_ioc", "search_term": "93.184.216.34"}'

Feed	Focus	Auth Required	Rate Limit
AlienVault OTX	General threat intel, pulses	Optional (API key for more)	Generous
AbuseIPDB	Community abuse reports	Free API key	1,000/day (free)
ThreatFox	Malware C2 indicators	None	Generous
URLhaus	Malware distribution URLs	None	Generous
GreyNoise	Mass scanning vs targeted	Free community API	Limited

Step 6: Co-hosted Domains

Most IP addresses host multiple domains (shared hosting, CDNs, cloud instances). Discovering co-hosted domains reveals the IP's broader context. A suspicious IP that also hosts 500 WordPress sites on a shared hosting provider is less concerning than one hosting three domains all registered last week with privacy-protected WHOIS.

# HackerTarget reverse IP lookup (100/day free)
curl -s "https://api.hackertarget.com/reverseiplookup/?q=93.184.216.34"

Cross-reference co-hosted domains with threat intelligence. If one domain on a shared IP is flagged for phishing, the other domains might be part of the same campaign or unrelated victims on shared infrastructure.

Step 7: Historical Context

Current data tells you what an IP is doing now. Historical data tells you what it has been used for. An IP that was clean last month but started appearing in threat feeds this week may indicate a newly compromised server or freshly provisioned attack infrastructure.

Historical passive DNS data (available through SecurityTrails, Farsight DNSDB, and similar services) reveals all domains that have ever resolved to this IP. This uncovers infrastructure changes, domain rotation patterns, and connections to other campaigns.

Step 8: Synthesize Findings

After collecting data from steps 1-7, synthesize the findings into an assessment:

Attribution: Who operates this IP? (organization, ISP, cloud provider)
Infrastructure type: Dedicated server, shared hosting, cloud instance, residential?
Services: What is running? Do the services match the expected purpose?
Reputation: Is it flagged in threat feeds? How many reports? How recent?
Anomalies: Anything inconsistent? (e.g., a "US company" hosted on a bulletproof provider in Eastern Europe)
Risk assessment: Based on all evidence, what is the threat level?

Automate This Workflow

MAGO runs all of these investigation steps automatically. Enter an IP address and receive a structured intelligence report with geolocation, WHOIS data, open ports, threat intelligence correlation, and risk assessment -- in seconds rather than the 15-30 minutes a manual investigation requires. Try a free IP scan.

Common Investigation Scenarios

Scenario: Suspicious Login Attempt

Your authentication logs show repeated failed login attempts from an IP. Investigation reveals: residential ISP in a country where you have no users, no PTR record, port 22/3389 open (likely compromised), AbuseIPDB shows 47 reports for brute force in the past 30 days. Assessment: compromised residential device running automated credential stuffing. Action: block the IP and the /24 subnet, check if any attempts succeeded.

Scenario: Phishing Email Source

An employee reports a phishing email. The sending IP traces to a cloud provider. Investigation reveals: domain registered 3 days ago, WHOIS privacy-protected, hosting a login page mimicking your company, TLS certificate from Let's Encrypt (free, no identity verification), no PTR record. Assessment: purpose-built phishing infrastructure. Action: report to the hosting provider's abuse team, add to blocklist, alert users.

Scenario: Vendor Risk Assessment

A prospective vendor provides their web application URL. Resolving the domain reveals an IP on a major cloud provider. Further investigation shows proper security headers, current TLS certificate with proper chain, clean reputation across all threat feeds, and appropriate DNS configuration including SPF/DKIM/DMARC for email. Assessment: basic security hygiene appears adequate. A full domain intelligence report would provide comprehensive vendor assessment.

References

Verizon 2025 DBIR -- exposed RDP as primary ransomware entry vector, credential abuse at 22%. MITRE ATT&CK -- T1590 (Gather Victim Network Information), T1596 (Search Open Technical Databases). NIST SP 800-61r2 -- Computer Security Incident Handling Guide. RIPE NCC -- RIPEstat API documentation for IP intelligence.