Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-Recon-CloudAssetShadowITDiscovery.
Unlock with Pro - from £29/user/moDetect Cloud Asset & Shadow IT Discovery via Internet-Wide Scanning Services in CrowdStrike LogScale
Adversaries performing Search Open Technical Databases (T1596) rarely scan a target's network directly — instead they query commercial internet-wide scan-database services such as Shodan, Censys, BinaryEdge, ZoomEye, and ONYPHE, which continuously crawl the entire public IPv4/IPv6 space and index open ports, service banners, TLS certificates, and known CVEs for every internet-facing host. This lets an adversary map an organization's external attack surface — including forgotten dev/staging environments, misconfigured cloud storage endpoints, unmanaged VMs, and other 'shadow IT' the security team never inventoried — without sending a single packet the target can attribute to them. Because the adversary's actual query happens against the third-party database and is invisible to the defender, the only observable telemetry is the re-indexing traffic these scanning services' own crawler infrastructure generates as they continuously re-scan the internet to keep their databases current. This detection treats that crawler traffic as an early-warning signal: it flags (1) perimeter traffic from known scanning-service IP ranges probing many distinct ports on a single asset (the banner-grab pattern used to populate these databases), and, more importantly, (2) scanning-service traffic that reaches a destination IP absent from the organization's own asset inventory — meaning a commercial scan database has just indexed infrastructure the defender did not know was internet-facing. That second signal is functionally identical to what an adversary running T1596 would discover, giving defenders a chance to find and remediate the shadow IT asset before it is weaponized under T1190 (Exploit Public-Facing Application).
MITRE ATT&CK
- Tactic
- Reconnaissance
LogScale Detection Query
// Alert 1: Inbound connections from known internet-wide scanning service ranges touching 5+ distinct local ports on a Falcon-monitored perimeter/DMZ host
#event_simpleName=NetworkConnectIP4
| ConnectionDirection=Inbound
| RemoteAddressIP4=/^(198\.20\.(69|70|71)\.|167\.94\.(138|145|146)\.|162\.142\.125\.|199\.45\.15[24]\.|195\.154\.108\.|71\.6\.135\.|64\.62\.202\.)/
| stats count(as=HitCount), distinct_count(field="LocalPort", as=DistinctPorts), earliest(ConnectionStartTime, as=FirstSeen), latest(ConnectionStartTime, as=LastSeen) by ComputerName, RemoteAddressIP4
| DistinctPorts>=5
| table([ComputerName, RemoteAddressIP4, DistinctPorts, HitCount, FirstSeen, LastSeen])
| sort(LastSeen, order=desc)
// Alert 2: run as a separate scheduled search — same scanner ranges reaching a LocalAddressIP4 not present in the KnownAssets watchlist
#event_simpleName=NetworkConnectIP4
| ConnectionDirection=Inbound
| RemoteAddressIP4=/^(198\.20\.69\.|167\.94\.138\.|162\.142\.125\.|195\.154\.108\.)/
| !in(field="LocalAddressIP4", values=$KnownAssetsWatchlist)
| stats count(as=HitCount), distinct_count(field="RemoteAddressIP4", as=DistinctSourceScanners) by LocalAddressIP4Two CrowdStrike CQL queries against ProcessRollup2-adjacent network telemetry (NetworkConnectIP4), applicable to Falcon-monitored internet-facing hosts. The first matches inbound connections from known internet-wide scanning-service ranges touching 5 or more distinct local ports on a single host. The second filters the same scanner ranges for connections reaching a LocalAddressIP4 not present in an imported KnownAssetsWatchlist, surfacing unmanaged/shadow hosts running the Falcon sensor.
Data Sources
Required Tables
False Positives & Tuning
- Authorized red team or third-party pentest infrastructure overlapping with commercial internet-scanning IP ranges
- Uptime/monitoring SaaS providers probing multiple ports for health checks from ranges not yet allowlisted
- Newly provisioned intentionally public-facing Falcon-monitored hosts not yet added to KnownAssetsWatchlist
Other platforms for THREAT-Recon-CloudAssetShadowITDiscovery
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Linux — Multi-Port TCP Connect Sweep Simulating Scanner Breadth Probe
Expected signal: Perimeter firewall/NSG flow log entries (CommonSecurityLog or CEF equivalent) recording 15-20 distinct DestinationPort values from the test source IP to <TARGET_IP> within a short window, with an allow or deny verdict per port.
- Test 2Linux — HTTP Request Using Known Scan-Database Crawler User-Agent
Expected signal: Web/application server access log entry for <TEST_WEB_HOST> recording the User-Agent string 'CensysInspect/1.1 (+https://about.censys.io/)' against the source IP that issued the request.
- Test 3Linux — Scanner Traffic Reaching an Asset Absent From the KnownAssets Watchlist
Expected signal: Perimeter firewall/flow log entries for the test source IP reaching <SHADOW_TEST_IP> on the probed ports, with no corresponding entry for <SHADOW_TEST_IP> in the KnownAssets watchlist or known_assets.csv lookup.
References (8)
- https://attack.mitre.org/techniques/T1596/
- https://attack.mitre.org/techniques/T1596/005/
- https://www.shodan.io/
- https://censys.io/
- https://about.censys.io/
- https://www.rapid7.com/research/project-sonar/
- https://viz.greynoise.io/
- https://learn.microsoft.com/en-us/azure/sentinel/normalization-schema-network
Unlock playbooks & atomic tests with Pro
Get the full detection package for THREAT-Recon-CloudAssetShadowITDiscovery — response playbook and atomic red team tests, plus investigation guidance and hunting queries.
df00tech Pro — £29/user/month