A help-desk ticket lands at 09:14. An analyst pasted a destination address from an EDR alert: a workstation reached 203.0.113.84 minutes after the user opened a newly downloaded installer from a public torrent site. The hash matches a MovieReaper-style trojan family circulating through compromised torrents across several countries. The SOC wants a block. The incident lead wants to know whether that single address is rented attacker infrastructure, a compromised shared host, or a clean CDN edge that malware briefly abused.
That decision rests on OSINT you can run before containment closes the window. The same workflow applies when ScanBox shows up behind a watering-hole redirect, when SparroWock-class backdoors phone home, or when a malicious npm package reaches a C2 host only after install-script defenses have already passed. Public sources turn one IP into hosting context, neighbor relationships, and a hunt plan your team can execute in machine-speed defense windows.
Start from the alert artifact, not the reputation score
Treat the IP as a pivot key. Collect the minimum evidence set that every later OSINT step depends on:
- Exact destination IP and port from the telemetry row
- UTC timestamps for first and last observed connections
- Process path, parent chain, and user context on the endpoint
- Any URL, SNI, JA3/JA4, or User-Agent captured on the proxy
- File hash or package name if delivery came from torrents, email, or npm
Write those five items into the ticket before you open external tools. Later pivots stay reproducible when another analyst repeats the work after TeamPCP-style arrest reporting names overlapping ASNs, or after ISC Stormcast episodes highlight a related campaign the same week.
Confirm what the address is hosting right now
Run a short live surface check. Prefer read-only, low-noise probes from an investigation jump host your network already allows outbound:
- Resolve reverse DNS and note whether the PTR looks like a provider template (customer-203-0-113-84.example-host.net) or a branded service name.
- Pull current RDAP/WHOIS for the prefix: registrant org, abuse mailbox, allocation date, and whether the range is marked as hosting, ISP, or cloud.
- Record open services visible in public scanners you already license (port set, TLS cert CN/SAN, HTTP title, SSH banner). Save the raw JSON, not screenshots alone.
- Compare the TLS certificate serial and SPKI hash against Certificate Transparency indexes for other names on the same key.
If the live banner shows a generic shared-hosting panel while your malware sample talks JSON on a nonstandard port, you are likely looking at a compromised tenant rather than purpose-built C2 hardware. That distinction changes whether you page the provider abuse desk with a takedown packet or expand the hunt for sibling tenants on the same /24.
Rebuild recent hosting history in public sources
Attackers rotate. Your OSINT pass needs history as much as a live snapshot.
Passive DNS and name history
Query passive DNS for every hostname that resolved to the IP in the last 30–90 days. Group results by first-seen and last-seen. A name that appeared only during your alert window often marks disposable campaign infrastructure. A name that sat on the IP for months and also hosts unrelated customer sites points at shared hosting or a long-lived compromised server.
Historical web captures
Pull archived page captures for any HTTP(S) hostname tied to the address. Look for panel titles, login forms, default server pages, or language that matches public write-ups of ScanBox loaders and similar watering-hole kits. Capture dates that line up with your first-seen telemetry strengthen the timeline you will hand to IR.
Malware and sandbox corpora
Search public malware databases and sandbox reports for the IP, the hash, and distinctive strings from the beacon. MovieReaper-style torrent lures, SparroWock command channels, and npm packages that evade install-script checks often leave the same destination across multiple submissions. Note which families and which countries appear in those reports so your geo conclusions stay tied to sample metadata rather than a single database city label.
Map the neighborhood without blaming the whole ASN
Once the address looks attacker-controlled or clearly compromised, expand one hop outward with disciplined scope:
- List same-/24 and same-ASN neighbors that share TLS certificates, HTTP titles, or reverse-DNS patterns with your seed IP.
- Check PeeringDB and looking-glass reachability for the prefix so you understand transit paths your scrubber and edge will actually see.
- Separate cloud marketplace exits from dedicated VPS ranges; rented clean cloud numbers show up in extortion and credential campaigns precisely because reputation scores stay soft on first use.
- When public reporting on arrests or takedowns (for example TeamPCP-related coverage) names tooling or panels, compare panel fingerprints only against your saved banners. Do not stretch attribution past overlapping infrastructure traits.
Document every neighbor you add to the hunt queue with a reason code: shared cert, same PTR pattern, same malware report, or same redirect chain. Reason codes keep the queue from becoming an unstructured ASN block.
Tie delivery path OSINT to the same IP pivot
IP investigation fails when delivery context stays siloed. Fold these checks into the same case file:
- Torrent and cracked-software delivery: Capture tracker announce URLs, payload mirror hosts, and any secondary download IPs referenced in the installer. MovieReaper-style campaigns often keep the C2 address stable while mirrors rotate.
- Watering-hole and ScanBox paths: Preserve the full redirect chain, referrer, and the IP that served the keylogger stage. The listed watering-hole domain and the ScanBox host may sit on different networks; hunt both.
- npm and other package managers: Record the registry package name, version, and any post-install or runtime URL. Packages that evade install-script defenses still resolve C2 names at runtime; your proxy and DNS logs become the OSINT ground truth.
Correlate those delivery IPs against the beacon IP. Shared hosting providers, overlapping certs, or identical HTTP server headers across stages tell you whether you are chasing one operator footprint or opportunistic reuse of compromised sites.
Detection steps your SOC can operationalize today
Translate OSINT findings into detections that fire on the next hit:
- Create a temporary indicator group for the seed IP, confirmed neighbor IPs, and hostnames from passive DNS with first-seen inside your case window.
- Alert on any internal host that resolves or connects to that group for 14–30 days, including after public feeds delist the address.
- Join proxy, DNS, and EDR rows on the same five-tuple and process GUID so a single beacon does not fragment across tools.
- Flag outbound connections that reuse the JA3/JA4 or URI pattern from your sandbox report even when the destination IP rotates inside the mapped neighborhood.
- For dual-stack endpoints, duplicate the hunts on IPv6 literals and AAAA answers tied to the same hostnames; IPv4-only tickets miss half the session.
Keep the detection ticket linked to the OSINT case ID. When machine-speed defense tooling auto-blocks a listed scanner, analysts still need the linked case to decide whether a full host replay is warranted.
Response actions after the OSINT picture firms up
Move from enrichment to action with a clear severity ladder:
- Confirmed C2 or loader host with internal contact: Isolate the endpoint, preserve memory and disk triage, rotate credentials for the interactive user, and block the IP plus reasoned neighbors at the edge and recursive DNS.
- Compromised shared host: Block at your edge, open an abuse ticket with RDAP contact data, attach timestamps, sample hashes, and packet or proxy excerpts. Ask for tenant isolation rather than a silent null-route that affects unrelated customers.
- CDN or platform edge briefly abused: Prefer URL, path, and Host-header controls over blanket IP denies. Record the platform ticket number beside your case so delisting later does not erase context.
- No internal contact, OSINT shows active campaign: Add the indicators to your watchlist, tune IDS signatures from sandbox network IOCs, and brief IT admins who own VPN, mail gateways, and package-allowlist controls.
Close the loop by writing a one-page timeline: delivery event, first DNS resolution, first connection, OSINT confirmation time, and containment time. That timeline is what leadership reads when the same wave appears in the next Stormcast briefing or vendor advisory.
Field checklist for the next malicious IP
- Freeze alert artifacts before touching external databases.
- Capture live RDAP, PTR, and scanner banners into the case store.
- Pivot through passive DNS, CT, archives, and malware corpora with dated queries.
- Expand to neighbors only with explicit reason codes.
- Fold torrent, watering-hole, and package delivery hosts into the same graph.
- Ship detections that survive IP rotation for at least two weeks.
- Choose response by infrastructure type: dedicated C2, compromised tenant, or abused platform edge.
OSINT does not replace packet capture or endpoint forensics. It gives IT administrators and cybersecurity teams enough public hosting truth to decide what to block, what to hunt, and what to hand to a provider before attribution hardens around a single noisy address.
