The Discord Crawler That Wasn't. How A Four-Year-Old PTR Record Becomes The Cover For A Weaponized Scraper. GCP IP Recycling Is The New Reputation-Laundering Channel.

An operator emailed our inbox this morning claiming the IP address 35.237.4.214 is a Discord embed proxy and demanding we stop reporting it. The email is paraphrased here without identification because the technical pattern is the interesting thing, not the operator. Their claim does not survive contact with the facts. The threat-intelligence community has been writing about this specific abuse pattern for two years, and today's email is the closing artifact for a clean public example of it.

Here are the facts in the order they refute the claim.

Discord does not own this IP in 2026. Discord operates approximately thirty-five IPv4 networks on its own autonomous system, AS49544, primarily out of the 66.22.192.0/18 family with regional CIDRs in Rotterdam, Brazil, Chicago, and Tokyo. The IP 35.237.4.214 belongs to Google Cloud Compute Engine, ASN AS15169, ARIN-allocated to Google LLC under the GOOGLE-CLOUD net handle. Google does not delegate sub-allocations on tenant change. There is no whois-layer mechanism by which 35.237.4.214 could currently belong to Discord.

Discord does not route its embed proxy through Google Cloud. Discord's developer documentation states that embed-proxy traffic for Activities flows through Cloudflare Workers under the domain pattern clientId-dot-discordsays-dot-com. User-facing media proxy is served from media-dot-discordapp-dot-net and images-ext-1-dot-discordapp-dot-net. None of those route through GCE.

Discord stopped using this specific IP almost four years ago. Mnemonic's public passive-DNS database returns nine historical resolutions for 35.237.4.214. Among them is one record worth flagging — crawl-35-237-4-214.ptr.discord.com, with a first-seen timestamp of September 2021 and a last-seen timestamp of September 2022. That was Discord's link-preview crawler using GCE for its outbound legs during a one-year window. Discord released the VM in late 2022 and migrated its crawler infrastructure to its own ranges. After Discord released the IP, it cycled through at least eight subsequent operators including a crypto-mining-themed hostname, an Indonesian retail-marketing subdomain, an RDP service, a residential Romanian gateway, and now a free dynamic-DNS pointer at chickenkiller-dot-com from the afraid-dot-org provider family. The current rDNS pool also includes throwaway domains on naputtaja-dot-fi and kr4nk-dot-net. Discord does not point production embed proxies at free dynamic DNS provided by an Australian hobby project.

The current tenant is a weaponized scraper, not Discord. AbuseIPDB shows four-hundred-nineteen reports from fifteen distinct organizations against this IP, with an abuse-confidence score of fifty-five and a most-recent report timestamped today at 10:34 UTC — approximately six hours before the operator's email landed in our inbox. The most recent reported behavior is User-Agent string Discordbot/2.0 against a German consumer-electronics forum, classified by the reporter under categories twenty-one (web-application attack) and nineteen (spoofing). Discord's actual link-preview crawler fetches URLs that users post in Discord channels. It does not bulk-scrape German consumer-electronics forums. Two patterns of activity are inconsistent — one of them is Discord, the other one is whoever is currently renting the GCE VM at 35.237.4.214 in 2026.

The User-Agent string is the smoking gun. The operator is sending Discordbot/2.0 from a non-Discord IP because the IP used to be a Discord crawler. The historical PTR is the cover, not coincidence. This is name-able as an abuse pattern, and the pattern is reproducible across every cloud provider that recycles VM IPs between tenants without notifying the threat-intel ecosystem of the tenancy change. The pattern has five steps.

First, acquisition. An operator spins a GCP or Azure or AWS VM and pulls passive-DNS history on the assigned IP.

Second, selection. If the IP has a notable prior tenant — Discord crawler, GitHub Actions runner, Slack link-preview infrastructure, a known SaaS vendor's reverse-proxy — the operator keeps the VM. The historical PTR is the value. If the IP has no interesting prior tenant, the operator burns the VM and tries another.

Third, User-Agent spoofing. The operator's scraping framework sends User-Agent strings consistent with the prior tenant. For the Discord-crawler historical association, the natural choice is Discordbot/2.0. For a GitHub Actions runner association, it would be a Go-default User-Agent. For a Slack link-preview association, it would be Slackbot-LinkExpanding/1.0. The choice of UA is determined by the choice of historical tenant, which is determined by the IP that was acquired.

Fourth, web application firewall bypass. Most production WAFs and bot-management products use combinations of User-Agent string plus historical-IP-reputation signal to determine whether a request is allowed, challenged, or blocked. A rule that reads "allow Discordbot user-agent from any IP that has historically resolved to a Discord PTR" lets every request from 35.237.4.214 through, even today, because the historical PTR is still indexed. The rule outlived the reason it was written.

Fifth, abuse-report harassment. When the IP starts collecting AbuseIPDB reports, the operator emails the reporters claiming the IP belongs to the prior tenant. If even one reporter retracts the report, the abuse-confidence score drops. If AbuseIPDB downweights the IP, downstream auto-blocks relax. The email arrives via Protonmail or another free-mail provider, claims authority based on a real or invented relationship to the prior tenant, and demands a retraction. The pattern is reproducible enough that any abuse-reporting team can detect it by setting a Gmail filter on inbound mail mentioning specific IP addresses from non-corporate domains.

Three structural reasons the threat-intel ecosystem is vulnerable to this pattern, in increasing order of difficulty to fix.

The first reason is that passive-DNS sources do not decay. Mnemonic, VirusTotal, SecurityTrails, FarSight DNSDB, and the rest are historical record by design. They do not apply a freshness penalty to old records. A defender reading PTR history for an IP sees the most-trusted prior tenant rise to the top of relevance ranking because the most-trusted prior tenant is the highest-signal data point in the dataset. The fix at the consumer end is to compute IP reputation primarily from the last twelve months of cross-source signal and to treat older signal as context, not weight. The DugganUSA BDE per-IOC scoring already favors recency; this is the externalization of the principle.

The second reason is that cloud-provider WHOIS does not update on tenant change. The IP allocation belongs to Google. Google does not republish sub-allocations when a customer VM moves to a different account. There is no authoritative current-tenant signal at the whois layer. The fix would require the cloud providers to publish a per-IP current-tenant manifest, which they will not do for the obvious reasons. The realistic fix at the consumer end is to apply a freshness penalty to every WHOIS-based trust signal and to weight current behavioral evidence (the most-recent twelve months of cross-source reports) over historical-record evidence (whois plus passive DNS).

The third reason is that allowlists outlive their justification. A WAF rule written in 2021 to permit Discord-crawler traffic against the 35.237.x.x range is still in production at organizations whose security teams have rotated since. The engineer who wrote the rule has moved on. The rule still exists. There is no operational mechanism in most enterprises to find and remove rules whose justification has expired, because justification is rarely documented in the rule and even more rarely tied to a calendar review cycle. The fix is an annual allowlist-review process in which every IP-range allow rule is re-validated against the current published infrastructure of the tenant the rule was written to permit. Almost no organization does this.

The forward-looking concern is that the GCP Discord example we are publishing today is one instance of a generalizable pattern that has only just begun to be operationalized. Watch for the same lifecycle against GitHub Actions runner IPs — the second-richest source of historical-trust receipts in the cloud-IP ecosystem after major SaaS crawler pools. Watch for the same lifecycle against Slack, Microsoft Teams, and Zoom link-preview crawler ranges, which are the collaboration-tool analog of the Discord case. Watch for it against major newsletter-platform crawlers like Substack, Beehiiv, and Buttondown, which are all using cloud-hosted outbound. Every former-corporate-IP that cycles back into a public cloud's general-purpose VM pool inherits whatever trust the prior tenant accumulated. Operators have started shopping for those specifically.

The defender posture this implies is a small set of habits that organizations can adopt this quarter without spending money. Re-validate every IP-range allowlist annually against the named tenant's currently-published infrastructure. Weight passive-DNS and whois evidence behind the last twelve months of behavioral cross-source signal. Filter inbound abuse-related correspondence for the pattern of free-mail-or-Protonmail handles demanding retraction of recent reports. Treat User-Agent string plus IP-historical-trust as a heuristic that produces false positives in the operator's favor and add behavioral signals — request rate, target diversity, time-of-day pattern — to the decision.

The IP 35.237.4.214 is on our IOC blocklist at BDE eighty since February 7, 2026. It is going to stay there. The operator's email was the closing artifact for this post. The bag of dicks remains in the corner. Location unchanged. Happy dining.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com