The 60-Minute Site: Phishing That Deletes Its Own Evidence
On 8 July 2026, Cloudflare shipped Drop — drag a folder into a browser and get a live site on a trusted workers.dev address, with no account required. It is a genuinely elegant developer tool. It is also a near-frictionless delivery surface for credential harvesting that self-destructs in one hour, taking your forensic evidence with it.
What changed, and why we're writing about it
Abuse of reputable cloud hosting for phishing is not new. What Cloudflare Drop changes is the friction — and friction is most of what stands between an opportunistic attacker and a working campaign.
Threat actors have leaned on workers.dev and pages.dev for years because pages served from Cloudflare's edge inherit a domain reputation that most URL-filtering engines are reluctant to block, arrive over valid TLS, and load fast from anywhere. Historically that still required registering an account. Drop removes the last step.
The mechanics that matter to a defender: you drag a folder or ZIP of static files into the browser, Cloudflare silently provisions a disposable sandbox account, and your content is live on a random workers.dev URL within seconds — no signup, no email, no CLI. The deployment stays public for exactly 60 minutes, then is deleted unless someone claims it into an account. Uploads are capped at 1,000 files and 25 MiB per file, and only static assets are served — no server-side code runs.
None of that is a vulnerability. It is a product working as designed. Our concern is the abuse profile that design creates, and specifically what it does to incident response timelines.
Four things that make this attractive to an adversary
We assess the abuse potential across four dimensions. This is analysis of a new capability, not a report of a specific campaign — but each dimension maps directly onto techniques we already observe against the wider Cloudflare Workers and Pages ecosystem.
1. Reputation borrowing — a trusted domain for free
A phishing page on a random workers.dev subdomain rides Cloudflare's aggregate reputation. Category and newly-registered-domain filters that would flag an attacker's own domain frequently pass shared platform hosts. TLS is automatic, so there is no certificate friction and no browser warning.
2. Anonymity — no account, no attribution
The anonymous path provisions a throwaway sandbox account with no email and no identity verification at deploy time. There is no registrant, no billing artifact, and nothing to subpoena in the first hour. Attribution work that normally starts with account metadata starts with nothing.
3. Ephemerality — evidence with a half-life
The 60-minute lifetime is the sharpest edge. A campaign only needs a burst — one SMS or email wave — and the infrastructure erases itself before most takedown and IR processes have even triaged the first report.
4. Agentic scale — deployable by a machine
Drop can be driven programmatically, including over MCP, so an AI agent can publish sites without a human in the loop. Combined with generated phishing content, the marginal cost of a fresh, disposable, uniquely-slugged page trends toward zero.
Why this specifically hurts incident response
Most phishing playbooks assume the malicious site outlives the investigation. You get a report, you triage, you pull the page, you extract indicators, you request a takedown, you brief the client. That sequence routinely takes hours to days — and it assumes the artifact is still there when you look.
A Drop deployment inverts that assumption. If the lure lands at 09:00, the site is gone by 10:00 whether or not anyone claimed it. By the time a SOC escalates and an analyst opens the URL, they may find nothing — no page to screenshot, no DOM to capture, no kit to fingerprint, no exfiltration endpoint to pivot on.
DFIR note — capture before you triage. The forensic value of a Drop-hosted lure decays to zero on a fixed one-hour clock. Detection cannot be the slow step. The moment a workers.dev link is flagged in mail or proxy telemetry, capture must fire automatically — full-page render, DOM, HAR, response headers, resolved IP and ASN, and a WARC — before a human ever reviews the alert. Treat the URL as a perishable exhibit.
How an abuse chain looks end to end
Mapped conceptually to adversary stages. We deliberately omit any operational payload detail — this is the shape of the threat for defenders, not a recipe.
- Stage the lure (Resource Development). A static credential-harvest page is assembled locally, often auto-generated, with exfiltration pointed at an off-platform endpoint.
- Publish anonymously (Acquire Infrastructure). The folder is dropped to the service; a random workers.dev URL goes live in seconds with valid TLS and no account trail.
- Distribute the link (Phishing). The URL is pushed via email, SMS, or chat. Trusted host reputation lifts deliverability past reputation-based filters.
- Harvest (Credential Access). The victim submits credentials; the static page ships them to the attacker's backend via a background request.
- Evaporate (Defense Evasion). At the 60-minute mark the deployment self-deletes. No takedown is needed; the infrastructure removes itself.
Detection and threat hunting
Because the served content is plain static HTML and CSS, the reliable signals are at the network and mail layers, not on the endpoint. The queries below are illustrative starting points — tune thresholds and allow-list the workers.dev subdomains your own developers legitimately use before alerting.
Surface inbound lures at the mail gateway (Microsoft 365 / Defender for Office 365, KQL)
// Inbound mail carrying Cloudflare Workers preview links
EmailUrlInfo
| where Url matches regex @"https?://[a-z0-9-]+\.workers\.dev"
| join kind=inner EmailEvents on NetworkMessageId
| where EmailDirection == "Inbound"
| summarize Recipients=dcount(RecipientEmailAddress),
FirstSeen=min(Timestamp) by SenderFromDomain, Url, Subject
| where Recipients >= 2 // low-and-slow tuning: adjust to your baseline
Catch first-contact egress before the clock runs out (Defender for Endpoint, KQL)
// Newly-observed workers.dev hosts users are actually visiting
DeviceNetworkEvents
| where RemoteUrl endswith ".workers.dev"
| where ActionType == "ConnectionSuccess"
| summarize Hits=count(), Devices=dcount(DeviceId),
FirstSeen=min(Timestamp) by RemoteUrl
| where FirstSeen > ago(1h) and Devices <= 5 // rare + new = suspicious
Hunting hypotheses
- Random-slug host. A high-entropy workers.dev label with no prior organizational history, first seen minutes after an inbound message referencing it.
- Mail then click then POST. A user opens a workers.dev link, then the page issues a background POST to an unrelated third-party domain — classic static-page exfiltration.
- Short-lived resolution. The host resolves and receives traffic for well under an hour, then goes cold. Correlate DNS first-seen with last-seen deltas.
- Brand keywords in path. Login, SSO, or MFA-themed paths or titles served from a platform host that has never carried your brand before.
- Referrer clustering. Multiple users reaching distinct random workers.dev hosts from the same SMS or email campaign inside a tight time window.
What we recommend
Blanket-blocking workers.dev is usually not viable — legitimate SaaS and internal tooling live there too. The workable posture is fast capture, tight monitoring, and user-side resilience.
- Automate capture on first sight. Trigger screenshot, DOM, HAR, headers, IP/ASN, and WARC the instant a workers.dev link is flagged — not when an analyst picks it up. Beat the 60-minute clock.
- Baseline your own usage. Inventory the workers.dev and pages.dev hosts your developers legitimately use, then alert on everything outside that set. New plus rare is the signal.
- Enforce phishing-resistant MFA. The end goal is credentials. FIDO2 and passkeys neutralize the harvest even when a lure lands and a user submits.
- Preserve mail evidence. The email or SMS often outlives the site. Retain full headers and the original URL so the investigation survives the deployment's deletion.
- Report fast, expect nothing. Submit abuse to Cloudflare, but treat takedown as a formality — the one-hour expiry usually wins the race. Value the report for pattern-tracking, not remediation.
- Brief the humans. Update awareness training: a padlock and the word "cloudflare" in the address bar are not trust signals. Judge the request, not the host.
A fair note on Cloudflare
Cloudflare built sensible guardrails into Drop — file and size caps, static-only serving, email verification to keep a site, and the short lifetime itself, which limits how long any single anonymous deployment can live. The same expiry that frustrates defenders also limits an attacker's dwell time on a given URL.
The point of this brief is not that Drop is dangerous software. It is that every reduction in deployment friction is also a reduction in attacker friction, and defenders should update their models the day a capability ships — not the day they catch the first campaign. For Drop, the update is simple: assume the evidence has a one-hour fuse, and build to capture inside it.
Related: FlareInspect — Cloudflare security assessment
Worried about your own Cloudflare footprint after reading this? FlareInspect is our open-source CLI framework for auditing a Cloudflare tenant's security posture — 25+ automated checks across DNS, SSL/TLS, WAF, and Zero Trust, with integration into Cloudflare Security Center. In testing it surfaced misconfigurations traditional scanners miss, including origin IP leakage and exposed credentials. Repository: https://github.com/ionsec/FlareInspect
