On a Tuesday morning, a regional hotel group’s SOC sees three abuse-feed matches within an hour. Two source IPs sit on a shared scanner blocklist known for probing booking engines and property-management portals. The third matches a feed tag often applied to infected consumer cameras and DVR fleets. The analyst applies the usual playbook: confirm the edge deny, ticket as “known bad noise,” and close. By Thursday, the same camera CIDR appears in underground listings advertising live RTSP and admin-panel access, and one hospitality probe IP that never completed a TCP handshake against the public WAF shows up in application logs against an exposed legacy check-in API on a partner VLAN.
That is the gap this article closes. Blocklist matches for commodity scanners and compromised IoT gear look similar in a SIEM table. The hunts they should trigger do not.
Why this week’s headlines sharpen the distinction
Industry reporting continues to document criminals selling access to Chinese-branded surveillance cameras, turning “botnet exit” labels into a marketplace for interactive sessions. Separately, scanners remain active against hospitality applications: booking stacks, channel managers, and guest Wi-Fi portals. ISC Stormcast coverage for September 17, 2026 sits in the same news cycle as those scan notes, reinforcing that perimeter telemetry from mid-September still rewards teams that treat vertical scanners as purposeful reconnaissance rather than generic internet background.
Modern SOC writing about cross-environment pivots lands in the same window. An IP that first appears as an inbound hospitality probe can later show up as an outbound beacon from a camera VLAN, a guest SSID, or a contractor jump path. Reputation feeds give you the match. Your hunt has to decide which story the match belongs to.
Separate the match class before you open the ticket
When an address lands on a public or commercial IP blocklist, classify it with three fields before you touch containment:
- List semantics: scanner, C2, spam, phishing sinkhole, compromised host, or mixed/unknown.
- Your exposure map: which listeners that IP could have reached in the last 14 days (VPN, RDP, camera NVR, PMS, guest portal, API gateway).
- Traffic direction and completeness: inbound SYN-only, full handshake, authenticated session, or outbound connect from an internal asset.
Camera-tagged and hospitality-scanner matches often share ASN diversity and high connection volume. They diverge on what “success” looks like. A hospitality scanner succeeds when it fingerprints a login path or CMS version. A sold camera session succeeds when someone interacts with a stream or admin UI. Your detection steps have to follow that success definition.
Detection steps that turn a list hit into evidence
1. Replay the contact window with application context, not only firewall counters
Pull edge firewall, reverse-proxy, and WAF events for the listed IP across at least 72 hours before the listing timestamp and 24 hours after. For hospitality-tagged sources, join on URI, Host header, user-agent family, and response codes. Look for sequences such as /admin, /xml/system.xml-style device paths, booking engine login POSTs, and odd Accept-Language or client fingerprints that walk multiple properties under one source.
Concrete example: Source 203.0.113.44 hits your public site 812 times in four hours. Firewall volume alone looks like a spray. Proxy logs show the same IP requesting /booking/login on property A, then /channel/api/v1/health on property B with identical TLS JA3 and a 40-second dwell between properties. That pattern supports a vertical recon hunt, even when every request returned 403 at the WAF.
2. Split IoT and camera matches onto management and media paths
For addresses tagged as cameras, NVRs, or generic IoT on abuse feeds, search internal NetFlow and firewall logs for:
- Outbound connections from camera, VoIP, or building-automation VLANs to the listed IP or its /24 neighbors.
- Inbound hits against RTSP (554), ONVIF-related HTTP paths, vendor default web ports, and manufacturer cloud-relay domains your devices still call.
- Auth anomalies on the camera vendor cloud tenant: new regions, new user-agents, sudden stream-view spikes.
When underground markets advertise camera access, the listed IP may be the compromised device itself, a relay, or a scanner mapping open cams. Correlate MAC/vendor OUI from DHCP, certificate subjects on the device web UI, and whether the IP ever answered an internal vulnerability scan as a camera. That triangulation keeps you from treating every IoT-tagged listing as volumetric DDoS residue.
3. Score “pre-listing” internal reach the same way you score post-listing drops
Many abuse feeds publish after repeated community sightings. Query DNS, proxy, and EDR for internal hosts that contacted the IP in the days before public listing. Prioritize:
- Privileged jump hosts and engineering bastions.
- Servers that hold PMS, payment-adjacent, or identity integrations.
- Endpoints that later show suspicious child processes or unusual scheduled tasks.
A single pre-listing HTTPS GET from a front-desk PC to a camera-relay IP deserves a host hunt. A thousand edge drops from a hospitality scanner against a hardened WAF deserve trend tracking and exposure review, with a tighter host hunt only when any request reached an origin or partner path.
4. Bind identity when the session crossed auth
If the listed IP completed any login attempt, join firewall/proxy tuples to IdP, VPN, and application auth logs on username, MFA outcome, and device posture. Password-spray sources rotate quickly; hospitality scanners sometimes reuse the same source while walking many tenants. Camera access brokers often reuse stolen vendor-cloud credentials from clean residential or VPS exits. Identity join is what turns three unrelated blocklist tickets into one intrusion narrative.
Response actions that match the hunt class
For hospitality and vertical application scanners
- Confirm which virtual hosts and APIs were reachable from the internet during the contact window, including staging and franchise-branded aliases.
- Force a config and patch review on any application version the scanner fingerprinting likely identified.
- Add temporary denser logging on login and API health endpoints for 48 hours while you watch for clean-neighbor follow-on sources in the same ASN or JA3 cluster.
- Notify franchise and MSP partners if shared booking infrastructure sits behind your edge; their origin may have answered while yours dropped.
For camera and IoT listings tied to access sales
- Isolate suspect camera VLANs from corporate identity and file shares while you inventory firmware and default credentials.
- Rotate vendor-cloud passwords and API tokens; revoke active stream sessions.
- Capture a short packet sample on RTSP/ONVIF paths to see whether the remote party requested live media or only banner data.
- Feed confirmed compromised device addresses back into your internal block and detection lists with a tag that forces the IoT hunt playbook next time, separate from scanner auto-close rules.
Shared containment hygiene
Block at the edge when policy allows, then keep the case open until the class-specific checks finish. Update the ticket with list name, first-seen in your telemetry, direction, apps touched, and identities involved. That record is what lets the next analyst avoid collapsing every reputation match into a single deny-and-done outcome.
A compact operating rule for the SOC
Give every IP blocklist match a two-question gate: What does this list claim the IP is? and Which of our listeners would make that claim profitable? Hospitality scanner hits drive application fingerprint and partner-origin hunts. Camera and IoT hits drive media-path, vendor-cloud, and VLAN isolation hunts. Same feed row, different evidence, different clock.
Use the mid-September scan activity against hospitality apps and the ongoing trade in surveillance-camera access as calibration. Your blocklists will keep mixing those populations. Your hunts succeed when your playbooks stop mixing them.
Takeaways you can implement this week
- Add a mandatory “match class” field on blocklist alerts: scanner-vertical, IoT/camera, C2, mixed.
- Maintain a 14-day exposure inventory for PMS, booking, camera, and guest-portal listeners.
- Require proxy or application join before closing hospitality-tagged sources as noise.
- Require VLAN and vendor-cloud checks before closing camera-tagged sources as botnet scrap.
- Keep pre-listing contact search in the default hunt, especially for privileged and partner-connected hosts.
