Most IP investigations stall because analysts collect every public record available, then still lack a clear answer to the only question that drives containment: who controls this address right now, and how shared is that control? Reputation scores, ASN labels, and fresh banners are useful inputs. They are not a tenancy decision. During weeks when edge bugs dominate practitioner channels, including the BeyondTrust Remote Support zero-day wave and related appliance exploitation, that distinction decides whether you quarantine one host, an entire hosting neighborhood, or nothing at all.
Teams get this wrong when an alert IP arrives during an exploit surge and the default reflex is to enrich everything in parallel. WHOIS, GeoIP, abuse mailboxes, Shodan-style banners, malware sandbox exits, and vendor scores all open at once. The ticket fills with screenshots while the containment clock runs. Shared cloud space looks malicious. Compromised residential exits look like dedicated C2. Sanctions-linked payment infrastructure gets treated the same as a random scanner. The investigation produces volume. It does not produce a durable block scope.
What tenancy means in an IP case
Tenancy is the operational claim that a specific actor or workload currently exercises meaningful control over the address. Control can mean dedicated hosting, a rented VPS, a compromised tenant behind a shared edge, a residential proxy exit, or a bulletproof range with rapid rotation. Your OSINT goal is to place the IP on that spectrum with enough confidence to choose monitor, soft deny, hard deny, or ASN-scoped hold.
Recent threat reporting makes the spectrum concrete. AI-assisted espionage against government Linux infrastructure often rides otherwise ordinary cloud and VPS ranges. Candiru-style spyware delivery through targeted ads can surface through CDN and advertising egress that looks clean to reputation engines. Payment and laundering infrastructure tied to actions such as the U.K. sanctions against Cryptomus shows how legal and abuse context can matter as much as malware sightings. Toy-malware families and creator-facing scam infrastructure recycle cheap hosting the same way ransomware callbacks do. One enrichment playbook does not fit all of those shapes.
Why parallel enrichment burns the wrong hours
Parallel enrichment feels thorough. In practice it delays the two outputs a shift lead needs: a block recommendation and a confidence statement. GeoIP tells you where a database thinks the address sits. It does not locate the operator. A clean vendor score can coexist with active campaign use. Live internet scans describe the host reachable now, which may differ from the host that touched your auth stack an hour earlier. Those limits are well known. The operational failure is spending analyst time proving them again on every ticket.
During edge exploit weeks, probe volume rises while per-IP blocklists lag. NetScaler, remote support, and VPN appliance chatter arrives faster than signature packs. If every probe IP gets a full dossier, your queue becomes a museum of half-finished WHOIS notes. Tenancy-first OSINT flips the order: gather only what changes the containment decision, then stop.
A field playbook that fits a single shift
1. Freeze the decision question
Write one sentence at the top of the case before you open any OSINT tab. Examples that work in real queues:
- Can we hard-deny this /32 for 24 hours without breaking a known partner?
- Do we need a temporary ASN hold on auth ingress only?
- Is this IP a reusable campaign peer or a one-off compromised tenant?
If the sentence is missing, enrichment becomes sightseeing.
2. Build a tenancy file in four layers
Keep the file short enough to hand to the next analyst without a briefing call.
- Identity layer: current reverse DNS, certificate subjects from recent handshakes if TLS is in play, and any historical names that disagree with the current PTR.
- Routing layer: ASN, announced prefixes, and whether looking-glass or RIR history shows a recent transfer or origin change.
- Service layer: ports and products that match your alert path. For a BeyondTrust-style remote support probe, prioritize evidence of admin panels, session brokers, and callback listeners over unrelated open services.
- Abuse layer: earliest public malware or scanner sighting, abuse-mailbox responsiveness, and any sanctions or financial-crime linkage that changes escalation.
Stop when two layers agree on shared versus dedicated control. Extra sources after agreement rarely change the block.
3. Time-box every source
Assign minutes, not aspirations:
- five minutes for reverse DNS, ASN, and prefix ownership
- five minutes for passive DNS age and certificate birth relative to first alert time
- five minutes for historical port or banner snapshots that predate your incident window
- ten minutes for abuse and sanctions context only when the IP sits near payment, crypto, or known bulletproof space
If the case still cannot support a containment choice after that budget, escalate for deeper attribution. Do not keep enriching in hope of certainty.
4. Score sharedness before campaign promotion
Promotion of a single probe IP into campaign indicators should require a sharedness score. A practical scale:
- Dedicated likely: stable PTR, long-lived certificates, consistent service set, sparse unrelated tenants in passive DNS.
- Shared cloud or CDN: broad neighbor diversity, short-lived names, overlapping clean and dirty tenants in the same /24 or service edge.
- Proxy or residential exit: city-level geo drift across sessions, ASN labels associated with mobile or ISP pools, auth telemetry that jumps between cities faster than travel allows.
- Compromised appliance or RMM neighbor: product fingerprints matching remote support, VPN, or edge management paths seen in current advisories.
Only dedicated-likely and appliance-neighbor cases usually justify widening from one IP to a peer graph on day one. Shared cloud and proxy exits need path-scoped controls first: auth ingress, admin consoles, callback egress.
Worked scenarios from current threat weather
Edge zero-day probe against remote support
Your IDS flags a source probing a BeyondTrust-related path while public chatter already treats the bug as actively exploited. Tenancy-first OSINT checks whether the source is a scanner farm on cheap VPS space, a compromised customer appliance, or a mixed hosting ASN already tied to prior edge RCEs. If certificates and reverse DNS show a generic VPS with rapid name churn, block the /32 on admin and VPN paths and hunt peer probes by request fingerprint. If product banners and historical ports show a real remote-support appliance, treat the IP as a possible victim-turned-pivot and join it to internal session evidence before a wide perimeter deny.
Government Linux espionage callback
An outbound connection from a Linux bastion lands on a cloud IP also used by ordinary AI and SaaS tenants. Reputation is mixed. Tenancy work compares passive DNS age, neighbor certificate issuances, and whether the destination answers only for a narrow service set at callback time. Shared tenancy pushes you toward egress allowlisting and host forensics. Dedicated tenancy with malware sightings that predate your alert supports a harder destination deny and upstream sharing of the peer set.
Spyware and scam delivery edges
Candiru-style zero-click delivery and creator brand-deal scams often front through advertising, CDN, or marketing infrastructure. The alert IP may look commercially legitimate. Your tenancy file should emphasize referrer and certificate timelines, not only ASN malice. Block decisions land on the specific delivery host and session join, while broader CDN ranges stay on heightened logging.
Sanctions-adjacent payment infrastructure
When an IP sits near cryptocurrency payment rails under active sanctions attention, abuse-layer OSINT changes the owner of the case. Network blocks still need tenancy evidence. Escalation to legal, fraud, and threat intel happens earlier because the business risk exceeds a routine scanner ticket.
Implementation details that stick in a SOC
Put the tenancy file in the same ticket template as severity and affected asset. Required fields: decision question, sharedness score, block scope proposed, evidence links, and stop time for enrichment. Wire your SOAR enrichments so the cheap layers run automatically and the expensive layers stay analyst-gated. Pair every shared indicator you publish with that sharedness score so peer teams know whether autodrop is safe.
Join external OSINT to one internal timeline before you page hosting: first seen in your logs, last seen, users or service accounts touched, and whether dual-stack or proxy drift appeared. Public ownership clues without that join produce confident tickets that miss the real blast radius.
Keep a short allow-corridor list for partners whose ASNs overlap hostile tenants. Country denies and ASN caps fail loudly when a shared cloud range hosts both your vendor and last night's probe source. Tenancy evidence is how you defend path-scoped policy instead of freezing partner traffic.
Actionable takeaways
- Start every IP case with a written containment question and a sharedness score.
- Collect reverse DNS, routing, service, and abuse evidence in that order, with a hard time budget.
- Widen from one probe IP to campaign peers only when tenancy looks dedicated or appliance-adjacent.
- On shared cloud, CDN, and residential proxy exits, prefer path-scoped denies and host replay over neighborhood autodrops.
- During edge zero-day weeks, measure investigation success by decision latency and block durability, not by count of enrichment tabs opened.
- Hand off a tenancy file, not a pile of screenshots, so overnight shifts can hold or widen blocks without redoing OSINT from zero.
OSINT for IP investigation earns its keep when it proves control and sharedness fast enough to shape policy while the exploit wave is still live. Exhaustive collection is optional. A tenancy decision is not.
