Stretchoid — making an anonymous Azure scanner verifiable without an official list
by shop owners for shop owners.
How the PARC feed for Stretchoid came about: an opaque recon scanner with no official list, on rotating Azure IPs. We derive the active IPs from two sources (CINS blacklist + OTX) and verify them by FCrDNS against *.stretchoid.com — 1,909 confirmed IPs.
Stretchoid is an internet-wide recon/port scanner with an anonymous operator. Not an SEO tool. There is no official IP list and no dedicated range — the scanners run on rotating Microsoft Azure IPs (AS8075). Still trackable, because Stretchoid sets a self-identifying reverse DNS *.stretchoid.com that is FCrDNS-verifiable. We derive the active IPs from two sources and confirm each one: 1,909 verified IPs. Part of our PARC Security feed.
stretchoid.json — view feed stretchoid.com (opt-out trap — deliberately not linked)
Where the IPs come from — two sources, one filter
Stretchoid publishes nothing. There is no official range list and no dedicated ASN — the scanners run on rented Azure IPs that rotate. A classic range block like Censys or ONYPHE is therefore impossible. Instead we use two observation sources and the same filter:
- CINS Army List (
ci-badguys, ~15,000 IPs, already in our catalog): reverse-resolve every IP, filter on the PTR *.stretchoid.com → 1,782 hits, all FCrDNS-confirmed. - OTX (AlienVault) passive records: 2,399 historical *.stretchoid.com hostnames, each resolved forward.
Both feed into the same test: if the name resolves to a real Azure IP → candidate; everything else is dropped.
The 127.0.0.1 signal: retired
When resolving the 2,399 OTX names, two thirds point nowhere — but not at random:
2,399 OTX hostnames:
1,176 → real Azure IP (live)
697 → 127.0.0.1 (retired)
526 → NXDOMAIN (dead)
127.0.0.1 is not an artifact but Stretchoid’s own record: expired scanner names are deliberately null-routed to localhost. Confirmed across four independent resolvers and the authoritative nameserver (Stretchoid runs its DNS on Azure DNS):
azpdws76.stretchoid.com (retired):
1.1.1.1 / 8.8.8.8 / 9.9.9.9 / OpenDNS → 127.0.0.1
authoritative ns1-37.azure-dns.com → 127.0.0.1
So 127.0.0.1 is a clean negative criterion — those names never enter the feed.
FCrDNS verification — 1,909 confirmed
A PTR alone proves nothing — anyone can set a reverse record to stretchoid.com. So we check bidirectionally (FCrDNS): the hostname must forward-resolve back to the same IP.
128.203.200.175 → azpdcgu5b3zl.stretchoid.com → 128.203.200.175 ✓
- CINS: 1,782 of 1,782 confirmed (100%).
- OTX delta: 138 new candidates (not in CINS) → 127 FCrDNS-confirmed, 11 dropped (no reverse record — including, correctly,
172.183.248.136, the website itself). - Total: 1,909 FCrDNS-verified IPs.
Reverse-DNS pattern
<random-string>.stretchoid.com (e.g. azpdcgu5b3zl, azpdcsqscjc2, azpdcgme7i2s)
No official block — scattered across half of Azure
The IPs spread across numerous Microsoft Azure prefixes (20.64.0.0/10, 20.160.0.0/12, 135.236.0.0/15, 40.124.0.0/16, 13.64.0.0/11 …) — shared with millions of other Azure tenants. Subnet whitelisting is out of the question; the only reliable signal is the FCrDNS-confirmed hostname.
The opt-out is a trap
The form on stretchoid.com presents itself as an opt-out — but the security community regards it as unreliable to misleading: the scans continue afterwards, and the form merely collects your name, email and the CIDR block you submit. Who runs it is undisclosed. Analyses (Hacker Factor, SANS ISC) attribute the scans specifically to hunting for vulnerable admin interfaces — recon with an offensive character, not a harmless service index.
Why the feed is rolling
Azure IPs rotate. The PARC feed is therefore a rolling, FCrDNS-verified snapshot of the currently observed Stretchoid IPs — not a static range. Sources: the CINS blacklist, OTX and our own server logs, each filtered and confirmed against *.stretchoid.com.