A hospitality chain SOC flags a burst of probes against booking and property-management portals. The source IP sits on a mid-tier VPS provider, reverse DNS is generic, and the first reputation lookup returns a middling score. Blocking that single address feels tidy. By morning the same probe signatures arrive from three neighboring hosts in a different ASN, and a helpdesk ticket shows an employee clicked a fake SSO link hours earlier. Teams that stop at the first IP miss the campaign. Teams that treat that IP as an OSINT pivot recover the shared hosting pattern, the certificate reuse, and the domains already in contact with staff.
Recent reporting on scans against hospitality applications, the reach of the 0ktapus threat group across more than a hundred firms, and SOC work on cross-environment pivots all point to the same operational need. An IP is a handle into infrastructure history, not a finished verdict. This article walks through a practical OSINT sequence that cybersecurity professionals and IT administrators can run when an IP lands in the queue.
Open with what the IP already told your own systems
Before you open external tools, freeze the local evidence. Pull the first and last seen timestamps, destination ports and paths, TLS SNI or Host headers, user agents, and any authenticated identity that touched the same session window. For inbound scanning, note whether the traffic hit public marketing sites, VPN gateways, or admin consoles. For outbound or post-auth contact, note the process, proxy user, and whether the destination answered on HTTPS with a browser-trusted certificate.
Write a one-line working hypothesis. Example: External VPS scanning hospitality booking paths on 443 and 8080 between 02:10 and 02:40 UTC, no successful auth, concurrent DNS lookups for a lookalike SSO hostname from two endpoints. That sentence keeps OSINT focused on confirming campaign scope instead of collecting trivia.
Passive DNS turns a host into a timeline
Passive DNS is the highest-yield first pivot for most IP investigations. Query historical resolutions for the IP and for every hostname your logs already associated with it. You want answers to three questions:
- Which domains pointed at this IP in the last 30, 90, and 365 days?
- Did those domains move together onto other IPs, suggesting operator-controlled infrastructure rather than a random shared host?
- Did any of those domains resolve briefly, long enough for a phishing window, then vanish?
In 0ktapus-style credential theft, operators rotate domains while reusing hosting patterns. Passive DNS often shows a cluster of lookalike login hostnames that shared an IP for a few days, then jumped to a new provider. That cluster becomes your enrichment set for DNS sinkholes, mail gateway blocks, and endpoint URL hunts. A single abuse listing for one IP understates the exposure when five sibling domains already appeared in employee browser history.
Record both forward and reverse associations. An IP that hosted brand-sso-login[.]com last week and now hosts a generic parking page still belongs in the hunt queue until you confirm no internal client contacted any prior name on that host.
Certificate transparency exposes reuse attackers leave behind
Certificate Transparency (CT) logs and related certificate search interfaces show which names appeared on certificates served from or requested for infrastructure tied to your IP. Search on:
- Exact hostnames from passive DNS and from your proxy or IDS SNI fields
- Parent domains and unusual SANs that group lookalikes
- Issuer patterns that recur across short-lived phishing certificates
Operators who automate kit deployment often request certificates for many hostnames in a short window, sometimes from the same account or with the same SAN packing style. When CT shows a burst of brand-themed names issued within hours of your first alert, expand monitoring to those names even if they never resolved to the IP you started with. That is how you catch the next landing page before reputation feeds catch up.
Compare certificate validity windows to your local contact times. A certificate issued two hours before the first employee click, served from the alert IP, then replaced after the domain moves, is strong campaign evidence. Pair that with hospitality or VPN path scanning from related IPs when the same operator is mapping victims while phishing credentials.
Hosting, routing, and neighbor context without over-trusting geo
After DNS and certificates, characterize the network position of the IP. Collect ASN, announced prefixes, hosting provider abuse contacts, and whether the address sits in a cloud, VPS, residential, or mobile range. Use BGP and prefix history only to understand churn and possible neighbor space, not as a moral score for the ASN.
Enumerate nearby addresses in the same /24 or provider project when your passive DNS cluster shows rapid rotation inside one provider. Hospitality application scanners often sweep from sequential or closely leased VPS addresses. Confirm with your edge logs whether neighbors already probed the same paths. That check converts one IP block into a short-lived watchlist sized to the actual wave.
Keep geolocation as a soft signal. Cloud exits and carrier NAT make city-level claims unreliable for enforcement. Country and ASN remain useful for admin-path policies and for prioritizing human review when credentials for privileged apps appear from unexpected egress.
Correlate OSINT with identity and cross-environment sessions
IP OSINT pays off when it meets identity. After you have a domain and certificate cluster, search IdP, VPN, email, and SaaS audit logs for those hostnames, for source IPs in the same hosting pocket, and for users who authenticated successfully in the same window. The 0ktapus victim set showed how live sessions survive password resets when session tokens and MFA-enrolled devices stay trusted. An IP investigation that stops at perimeter drops leaves those sessions untouched.
For SOCs defending cross-environment pivots, map the same infrastructure indicators across on-prem proxies, cloud access logs, and endpoint DNS. An employee who resolved a CT-linked hostname on a laptop, then later produced an unusual API token use from a cloud workload, is a pivot chain. The original alert IP is only the first node.
A compact OSINT checklist for each alert IP
- Local first/last seen, ports, paths, SNI/Host, and identities
- Passive DNS for the IP and for every related hostname
- CT and certificate SAN clusters for those names
- ASN, prefix, provider type, and neighbor probes in your own edge data
- Internal DNS, proxy, mail, and IdP hits on the expanded indicator set
- Session and token review for any user who touched the cluster
Response actions that match campaign scope
Block or rate-limit the original IP at the edge when traffic is clearly hostile, then extend controls to the OSINT-derived set with a defined lifetime. Prefer hostname and URL controls for phishing clusters, because the IP may change while the certificate and domain pattern continue. Sinkhole or alert on passive DNS names that staff already resolved.
Open tickets with hosting providers using concrete evidence: timestamps, probe paths, certificate subjects, and sample payloads. Parallel that with internal actions: force step-up or session revocation for exposed users, reset refresh tokens for SaaS apps in scope, and hunt for follow-on access from clean IPs that appear in the same user timeline.
When the IP looks like a compromised shared host rather than dedicated attacker infrastructure, constrain your network blocks to reduce collateral damage and lean on hostname, path, and identity controls. Shared hosting still warrants a full contact hunt for every name that resolved there during the window.
What good looks like after thirty minutes
A finished first-pass package for leadership and the next analyst should include the seed IP, the passive DNS name set, the CT-linked domains, the hosting summary, internal contact counts by hostname, and the identity actions already taken. That package travels cleanly into SIEM saved searches and into playbooks for the next hospitality scan wave or SSO phishing burst.
OSINT for IP investigation is the craft of turning one network address into a bounded map of shared infrastructure, then closing the sessions and paths that map still touches. Passive DNS and certificate transparency give you that map faster than waiting for the next reputation update, and they keep your response sized to the campaign rather than to a single leased address.
