TL;DR: 242,666 new scanning IPs geolocating to Hong Kong were observed in seven days, according to GreyNoise, but 99.7% never completed a TCP handshake, meaning the addresses could not be verified as real sources and likely polluted detection datasets with ghost infrastructure. The problem is not volume alone, but unverified source trust, which makes IP-centric scoring noisy and operationally brittle.
At a glance
What this is: GreyNoise found that a large surge of scanning IPs geolocating to Hong Kong was mostly unverified because almost none completed a TCP handshake.
Why it matters: This matters because defenders that count or block source IPs without verifying connection legitimacy may absorb large amounts of noise and miss the smaller set of real scanners that actually complete sessions.
By the numbers:
- 99.7% of those IPs never completed a single TCP connection.
- Only 702 IPs geolocating to Hong Kong actually completed TCP handshakes.
- UCLOUD surged 472% in session volume to become the top ASN by session volume in GreyNoise data.
Context
Scanning telemetry only becomes useful when the source address is verified, because raw IP counts can exaggerate activity that never amounted to a completed session. In this case, GreyNoise describes a large burst of spoofable traffic that appeared in observation data but could not be confirmed through TCP handshake completion.
The identity and governance issue is not whether an address appears in a dataset, but whether the control plane can separate confirmed infrastructure from unverified source claims. Without that distinction, analysts can overrate noise, underrate real multi-protocol scanners, and degrade trust in downstream detections.
Key questions
Q: How should security teams handle unverified scanning IPs in detection pipelines?
A: Treat unverified source IPs as lower-confidence telemetry until they complete a handshake or otherwise prove origin. Keep them out of primary risk scoring, separate them from confirmed scanners, and avoid letting geolocation or ASN labels drive enforcement on their own. The goal is to preserve signal quality before enrichment and blocking decisions amplify noise.
Q: Why do spoofable IPs create problems for threat intelligence and blocklists?
A: Spoofable IPs can look real enough to inflate counts, but they never prove the source actually existed as observed. That weakens attribution, pollutes reputation baselines, and can push defenders toward blocking the wrong infrastructure. The impact is especially severe when one noisy fleet outnumbers the smaller set of verified scanners.
Q: What are the signs that scanning telemetry is being distorted by ghost infrastructure?
A: Look for very high IP counts with minimal handshake completion, weak or absent payload evidence, and a large gap between observed source volume and verified sessions. A sudden ASN or region shift can also indicate that the dataset is reflecting rotating infrastructure rather than stable scanner behaviour.
Q: What should analysts do when high-volume scanning does not match verified activity?
A: Reweight the data toward confirmed sessions, repeated protocol use, and consistent behaviour across sensors. High volume alone should not drive escalation if most sources never complete TCP and do not generate exploitation signals. That mismatch usually means the dataset needs source validation before it can support response decisions.
Technical breakdown
Why incomplete TCP handshakes produce spoofable scan data
A TCP three-way handshake is the basic exchange that confirms two endpoints can both send and receive traffic. When GreyNoise says an IP is spoofable, it means the observed source never completed that exchange, so the address cannot be treated as a verified origin. That matters because many reputation and hunting workflows assume the source IP is real once it appears repeatedly. In practice, spoofable traffic can inflate counts, mask true scanning patterns, and create false confidence around where activity is coming from. The control problem is verification, not volume.
Practical implication: Treat handshake completion as a trust gate before you promote source IPs into scoring, blocking, or attribution workflows.
Why scanning datasets need source verification, not just enrichment
Enrichment works only when the underlying event is real. If a platform ingests unverified source addresses, then geolocation, ASN, and reputation labels are all attached to evidence that may never have represented an actual scanner. That creates a governance problem for threat intelligence: the dataset starts to look more complete while becoming less reliable. The article also shows how quickly the signal can shift when infrastructure rotates across regions and providers. A mature pipeline therefore needs provenance checks, not just more tags and more sources. See the NHI Lifecycle Management Guide.
Practical implication: Build filtering rules that separate confirmed scanners from unverified IPs before enrichment and correlation expand the noise.
How multi-protocol scanning hides inside high-volume hosting infrastructure
The signal-bearing traffic in this report came from a much smaller set of IPs that actually completed connections and scanned MySQL, SSH, SMB, and RDP across many countries. That is a classic scanning pattern: modest IP counts can still produce broad operational impact when the traffic is real and multi-protocol. The article also notes relay and tunneling characteristics inside some hosting clusters, which can make ordinary cloud or VPS environments look similar from the outside. Detection therefore needs behavioural context, not just hostname or ASN labels. See the Network Ports and Protocols Security Guide.
Practical implication: Correlate protocol mix, session volume, and handshake success before deciding whether a source is benign hosting or active scanning infrastructure.
NHI Mgmt Group analysis
Verification, not volume, is the governance boundary that matters here. A detection programme that cannot distinguish confirmed source addresses from spoofable ones has already lost analytical fidelity. GreyNoise’s data shows how quickly a quarter-million unverified IPs can swamp the same view that should surface the smaller set of real scanners. Practitioners should treat source verification as a control requirement, not a reporting preference.
Ghost scanning infrastructure is a useful named concept for this pattern: infrastructure that appears in telemetry at scale but never proves its source identity through a completed session. That is not merely noisy data. It is a governance failure in attribution, confidence scoring, and response prioritisation, especially when infrastructure rotates rapidly across regions and ASNs.
The identity angle is about trust in source claims, not user identity. Even outside classic IAM, security teams still govern claims about who or what generated traffic. Zero Trust Identity Guide is relevant here because the same principle applies at the sensor edge: trust should follow verification, not appearance. The practitioner implication is to make provenance part of the decision path before a source becomes a control input.
Real scanning activity can be buried by an overrepresented spoofable fleet. The report shows a small number of confirmed scanners reaching many countries and probing multiple services, while the majority of observed addresses never completed a handshake. That asymmetry means teams should not optimise only for scale. They should optimise for the ratio of verified to unverified activity, because that ratio determines whether intelligence is actionable.
This pattern aligns most closely with NIST-CSF detection and data quality concerns, plus MITRE-ATT&CK reconnaissance behaviour. The core issue is not a compromise event but the reliability of the telemetry that feeds detection, hunting, and blocking decisions. Practitioners should therefore govern ingestion quality as carefully as they govern alert thresholds, because poor source trust contaminates both.
What this signals
Source verification is now a telemetry quality issue, not just an attribution issue. Security teams that rely on IP reputation without a handshake-based trust check will keep promoting noise into decision systems. The practical shift is to treat confirmation status as a first-class field in hunting, blocking, and enrichment workflows.
Cloud-scale scanning now moves fast enough that static baselines break quickly. When infrastructure rotates across ASNs and regions within days, defenders need behavioural thresholds that survive provider churn. The programme implication is to weight protocol behaviour and session proof above the apparent geography of the source.
Verified activity should outweigh ghost volume in every triage path. The small set of confirmed scanners matters more than the massive unverified fleet because it is the only traffic that can credibly support response action. That makes source provenance a control objective, not an analyst preference.
For practitioners
- Verify source legitimacy before enriching IP data Require handshake completion or equivalent proof of origin before IPs enter scoring, correlation, or attribution workflows.
- Separate confirmed scanners from spoofable noise Tag unverified source addresses distinctly so analysts can exclude them from reputation baselines and watchlist generation.
- Recalibrate blocklists around behaviour, not count Weight protocol mix, session completion, and repeat scanning evidence more heavily than raw IP volume or geolocation labels.
- Track rapid ASN rotation as a detection signal Monitor abrupt shifts in source regions and provider concentration because fast turnover can indicate a scanning infrastructure reset.
Key takeaways
- The central risk is not the appearance of scanning volume, but the contamination of detection datasets by source addresses that never proved themselves through a TCP handshake.
- GreyNoise’s figures show a sharp split between ghost traffic and confirmed activity, which means the smaller verified set is the one defenders should prioritise.
- Teams should validate source origin before enrichment, scoring, or blocking so that telemetry quality does not collapse under unverified infrastructure noise.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Zero Trust Identity Guide · Network Ports and Protocols Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and Network Services are Monitored | The article is about monitoring quality and distinguishing real from unverified network activity. |
| ID.AM-04 — Inventories of the Information and Communication Technology (ICT) Assets Are Maintained | The post stresses that source datasets need trustworthy asset and source inventories. | |
| Recommendation — Strengthen network monitoring so source validation happens before unverified scanning data affects triage. Maintain validated source inventories so ghost infrastructure does not pollute detection baselines. | ||
| MITRE ATT&CK | TA0043;TA0007 — Reconnaissance; Discovery | The traffic described is internet-scale scanning and probing behaviour. |
| Recommendation — Map verified scanning patterns to reconnaissance techniques and prioritise hunting around repeated protocol probes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The issue is the integrity of observational data used in security operations. |
| Recommendation — Use audit and telemetry controls to preserve provenance and prevent noisy source data from distorting decisions. | ||
Key terms
- Non-Spoofable IP: A non-spoofable IP is a source address that can be tied to observed activity with confidence, rather than a forged address that appears in reflection or amplification traffic. This distinction matters because defensive lists are more reliable when they represent real, accountable sources.
- TCP Handshake: The three-step connection setup that confirms both endpoints can send and receive traffic. When a scanner never completes the handshake, analysts lose confidence in the source address as a verified origin, which changes how the event should be scored, enriched, and acted upon.
- Ghost Infrastructure: Infrastructure that appears at scale in telemetry but does not behave like confirmed, attributable source systems. The term is useful when noisy or rotating assets pollute datasets faster than defenders can verify them, reducing the reliability of geolocation, ASN, and reputation-based analysis.
- Session Volume: The number of observed network sessions associated with a source or infrastructure cluster over a period of time. High session volume can indicate real activity, but without handshake verification and behavioural context it can also overstate the importance of untrusted or spoofed source data.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org