SharePoint Phishing on Cloudflare Workers

TL;DR — PhishEye analysed a live SharePoint credential-phishing chain built on Cloudflare Workers. A Cloudflare-fronted lure (turnervault[.]net) impersonates SharePoint Online with a targeted "shared document" and a fake "I'm not a robot" check. The checkbox runs a one-line atob() redirect to a *.workers.dev second stage that is a cloaked JavaScript loader: it shows "Preparing your secure document…", polls a /lp/ endpoint, and only renders the credential form for a valid victim session, looping forever for everyone else. The workers.dev back end is not one site but a platform: at least five auto-provisioned p-<hex>.workers.dev accounts ran the same loader between April and July 2026. Separately, we compare a cruder, self-hosted SharePoint kit ("Enter Your SharePoint") and explain why a large "IOC list" bundled with these reports was a different, unconfirmed set. All indicators are defanged; nothing here is a how-to.

About this analysis. Findings come from first-hand, view-only research by the PhishEye anti-phishing team on 14 July 2026: passive DNS, urlscan.io's stored captures, header and static-content inspection, and rendering the loader in an isolated sandbox. We did not submit any credentials or interact with any form. The final credential page is session-gated and did not render to us; where we could not confirm something, we say so. Live URLs are defanged for safe handling.

SharePoint-on-Workers chain at a glance
Stage 1 (lure)	turnervault[.]net, behind Cloudflare, impersonating SharePoint Online
Lure theme	"Turner Construction Company has shared a restricted document" · fake I'm not a robot
Redirect	Checkbox → 650 ms timer → window.location.href = atob(<base64>)
Stage 2 (kit)	*.p-436szmjv.workers.dev — a cloaked JS loader on Cloudflare Workers
Cloak	/sp/ shell → fetch('/lp/') → document.write(); non-victims loop on "Loading…"
Platform	5+ auto-provisioned p-<hex>.workers.dev accounts, April–July 2026
Durable indicators	The loader signature and the p-<hex>.workers.dev pattern, not the rotating lure domains

What we found

Two things arrived together in a report: a "SharePoint" phishing page and a long list of domains. Pulling on the thread showed something more interesting than a single page. The credential theft runs as a two-stage chain hosted on free Cloudflare infrastructure, the back end is a repeatable platform rather than one site, and the domain list turned out to be a separate, unrelated problem. This post documents the chain, maps the platform, and draws out the detection and takedown lessons.

Stage 1: a Cloudflare-fronted lure and a one-line redirect

The entry point is turnervault[.]net, a domain sitting behind Cloudflare (it resolves into Cloudflare's 104.21.x / 172.67.x ranges and uses Cloudflare nameservers). The page is a believable SharePoint Online imitation: SharePoint-style branding and colours, a message that "Turner Construction Company has shared a restricted document with you", a fake file tile (Project Transmittal.PDF · 5 files · 7.4 MB Total), and a footer reading © 2026 Microsoft SharePoint. System ID: SP-44910. Naming a real company makes the lure feel specific and legitimate.

Instead of a login box, stage 1 shows a fake "I'm not a robot" check. This is social engineering, not a real CAPTCHA. Ticking it runs a short script:

function triggerRedirect() {
  document.getElementById('verifyBox').classList.add('checked');
  setTimeout(function () {
    // base64-encoded destination
    var gate = "aHR0cHM6...";        // decodes to the workers.dev second stage
    window.location.href = atob(gate); // decode and redirect
  }, 650);
}

The only "obfuscation" is Base64: atob() decodes the gate string to the real destination. Decoding it yields a https://<name>.p-436szmjv.workers.dev/sp/… URL. This pattern (a benign-looking first page that hides its destination in a Base64 blob and redirects on a fake human check) is common because it keeps the malicious URL out of the initial HTML and out of link scanners that do not execute JavaScript.

Stage 2: a cloaked loader on Cloudflare Workers

The second stage is served from Cloudflare Workers on a *.workers.dev subdomain. Requesting it does not return a login page. It returns a tiny HTML shell whose whole job is to load the real content later:

• A Microsoft-blue spinner (#0078d4) and the text "Preparing your secure document…".
• Randomised CSS class names (_hgh9lz, _0p8diw, _r0gyak) so there is no stable class to signature.
• A <noscript> block so non-JavaScript crawlers see only "JavaScript Required".
• One script that, after two seconds, fetches a second path and rewrites the page with whatever comes back:

fetch('/lp/', { credentials: 'same-origin' })
  .then(r => r.text())
  .then(d => { document.open(); document.write(d); document.close(); })
  .catch(() => location.reload());

The trick is the gate at /lp/. For a valid victim session (arriving through the lure chain with the right token), /lp/ returns the credential page, which document.write() paints over the loader. For everyone else (a researcher, a sandbox, a scanner, or a direct visit) /lp/ returns the same loader again, so the page loops forever on "Loading…". We rendered the live URL in an isolated browser and confirmed the behaviour: the tab polled /lp/ repeatedly and never left "Preparing your secure document…". The response also carries x-robots-tag: noindex, nofollow, noarchive and cache-control: no-store, and the content only ever exists after a document.write(), so it is absent from the initial HTML. That combination is why automated scanners record this stage as blank or "offline" when it is simply cloaked.

Because the final credential page is session-gated, we did not capture it, and we will not guess its exact fields. Structurally it is a credential-harvesting form; the theft happens after the gate opens.

The `p-.workers.dev` platform

The most useful finding is that the second stage is not a single deployment. Every deployment we mapped sat on a workers.dev account subdomain of the same shape, p-<8 characters>.workers.dev. Searching public scan history for the loader's "Loading…" shell surfaced the same kit across at least five distinct accounts, several of them live for well over a week:

Workers account	Worker(s) observed	Activity window
p-436szmjv.workers.dev	xwsjl-jjhs-t5dl, lsuqq-bknz-vft1	Apr, Jul 2026
p-2f98e49d.workers.dev	pt-lures-… ("SharePoint — Documents"), hub-files-… ("Shared with you — OneDrive")	Jun–Jul 2026
p-mv4ac1tf.workers.dev	xfvhg-pmsm-npe5	Jul 3–13, 2026
p-t2ctp0rk.workers.dev	hub-note-k4in	Jul 3–13, 2026
p-kvdxuk29.workers.dev	app-share-auj8	Jul 10, 2026

The worker names alternate between semantic labels for the document-share theme (hub-files, hub-note, app-share, and, tellingly, pt-lures) and random three-part strings for the loaders (xwsjl-jjhs-t5dl). The theme spans SharePoint and OneDrive "shared with you" document lures. In other words: one toolkit, provisioned across many throwaway Cloudflare accounts, fronted by rotating lure domains. The free workers.dev subdomain gives every deployment Cloudflare's TLS, edge delivery, and reputation for nothing.

A second, cruder operation for contrast

Not every "SharePoint" page is this polished. The first sample in this reporting was a different kit that brands itself, in its page title, "Enter Your SharePoint": a generic login card with no real Microsoft branding, an email and password field, and a button. It posts the credentials to a /api/v1/authenticate endpoint and then always shows a fake Network error: Handshake failed, so the victim blames a glitch. We tracked that template across ten self-hosted hosts between February and July 2026 (five still live), on cheap European and CIS virtual servers and free dynamic-DNS names, with a Telegram-adjacent hosting footprint.

The two operations are different actors with different tradecraft: one is a professional, cloaked platform on Cloudflare Workers; the other is a low-effort template on self-hosted boxes. They are worth showing side by side because defenders meet both, and because a single "SharePoint phishing" label hides very different response paths.

The IOC-triage trap

The report that started this also carried a list of 43 domains presented as indicators for "this" phishing. When we resolved them, they scattered to 39 different IPs across 17 countries with no shared hosting, roughly two-thirds sat on free dynamic-DNS providers, and the operator names read like gamer or CIS handles. Only one of the 43 actually hosted the phishing page. Cross-referencing a sample of the domains and their IPs against abuse.ch ThreatFox returned no matches, and the ones we checked had no public scan history as victim-facing pages.

The honest read: that list is not this campaign's front-end infrastructure. It is a separate collection of self-hosted servers in an adjacent ecosystem whose exact function we could not confirm. Bundling it with the phishing page would have misrouted takedowns (you report a phishing page to a host, not a free-DDNS provider) and polluted a detection feed. The lesson is a routine one for analysts: before you action a list, cluster it. Campaign infrastructure concentrates on a few hosts; an aggregated feed scatters. If the "IOCs" for one page span 17 countries and 39 IPs, they are probably several unrelated things.

Why this is hard to detect and take down

Everything about the Workers stage is chosen to frustrate defenders:

• Reputable, un-blockable parent domain. You cannot blocklist workers.dev without breaking a large slice of the legitimate web, so the malicious subdomains hide among real ones.
• Cloaking by session gate. Static crawlers, sandboxes, and link scanners see only the loader, never the credential page, so many never flag it.
• No content in the initial HTML. The page is assembled by document.write() after a fetch, defeating signatures that read the first response.
• Disposable, auto-provisioned back ends. A fresh p-<hex>.workers.dev account and worker is free and takes minutes, so burning one URL does little.
• Free TLS and edge delivery. Every stage looks fast and "secure" (a padlock) to the target.

Takedown then hits the same wall we documented in our Cloudflare Drop analysis: Cloudflare can act on content it hosts on Workers, but the reporting path is a manual form, and the documented abuse-report API returns 401 "client is not authorized to do this operation" for anti-phishing teams trying to automate it. The deploy side is instant and free; the takedown side is not.

How to hunt and defend

For detection and response teams:

• Deobfuscate the gate. When a "verification" page hides its next hop in a Base64 blob, decode the atob() argument and pivot on the destination host and path (/sp/, /lp/) rather than the friendly first page.
• Signature the loader, not the domain. The durable indicators here are the loader's behaviour (the "Preparing your secure document…" shell, the /sp/ → /lp/ two-request pattern, document.write() assembly) and the p-<hex>.workers.dev account pattern, not the rotating lure domains.
• Render, do not just fetch. A cloaked kit that gates on a session will look blank to a fetch. Analyse suspected workers.dev phishing in an instrumented browser that executes JavaScript, in-region, with the referring lure where possible.
• Deploy phishing-resistant authentication. These are plain credential-capture pages, not real-time relays, so passkeys or FIDO2 security keys defeat them outright, and phishing-resistant MFA blunts the value of any stolen password.
• Report to the host that can act. For workers.dev content, Cloudflare is the host; file the abuse report with the exact URL and evidence, and treat recycle (the next p-<hex> account) as the metric that matters.

Indicators of Compromise (defanged)

For detection and blocklisting only. Do not open in a browser. The lure domains rotate; treat the loader signature and the p-<hex>.workers.dev pattern as the durable indicators.

Stage 1 lure

turnervault[.]net            # Cloudflare-fronted SharePoint "shared document" lure

Stage 2 — Cloudflare Workers loader accounts / workers

xwsjl-jjhs-t5dl[.]p-436szmjv[.]workers[.]dev
lsuqq-bknz-vft1[.]p-436szmjv[.]workers[.]dev
pt-lures-73176f8b[.]p-2f98e49d[.]workers[.]dev
hub-files-3eab[.]p-2f98e49d[.]workers[.]dev
xfvhg-pmsm-npe5[.]p-mv4ac1tf[.]workers[.]dev
hub-note-k4in[.]p-t2ctp0rk[.]workers[.]dev
app-share-auj8[.]p-kvdxuk29[.]workers[.]dev

Loader tells: page text Preparing your secure document... · a /sp/ shell that fetch()es /lp/ and calls document.write() · randomised CSS class hashes · Microsoft-blue #0078d4 spinner · x-robots-tag: noindex, nofollow, noarchive.

Separate, cruder "Enter Your SharePoint" kit (different operation, self-hosted): page title Enter Your SharePoint · POST to /api/v1/authenticate · fake error Network error: Handshake failed.

Bundled domain list, unconfirmed and not this campaign's front end. These 39 domains arrived with the report but do not belong to the Cloudflare Workers chain above. They do not cluster (each resolves to a different IP), none appears in abuse.ch ThreatFox, and only spum[.]port0[.]org (which points at the "Enter Your SharePoint" host) has ever hosted a phishing page. We include the still-live subset (resolving on 14 July 2026) for reference and blocklisting, tagged as adjacent, self-hosted infrastructure of unconfirmed function. See The IOC-triage trap for why they are listed separately, not as campaign indicators.

# UNCONFIRMED / adjacent ecosystem — resolving 2026-07-14. NOT the Cloudflare Workers campaign front end.
31ch[.]virhost[.]xyz
after[.]crabdance[.]com
amorfati[.]ext[.]io
archi[.]fluxus[.]org
avs22[.]ignorelist[.]com
build[.]csproject[.]org
denisprog[.]mooo[.]com
dlore[.]mooo[.]com
ect[.]marzik[.]name
fninja[.]ignorelist[.]com
genshinlover[.]minecraftnoob[.]com
german[.]abrdns[.]com
hazzi[.]twilightparadox[.]com
iot123[.]mooo[.]com
khulster[.]csproject[.]org
kirboro[.]org
klausvps[.]duckdns[.]org
list[.]mikata[.]ru
market[.]diskshop[.]abrdns[.]com
meow[.]kesa[.]abrdns[.]com
meowksandr[.]spacetechnology[.]net
mh[.]picolino[.]dev
msn[.]abrdns[.]com
naparkovke[.]tdkare[.]ru
nikitasliva[.]mooo[.]com
nosamba[.]myaddr[.]tools
pl[.]sed0y[.]ru
powerbalance[.]mooo[.]com
prewayback[.]kepa2012[.]xyz
romaroma[.]chickenkiller[.]com
ru[.]czarpivo[.]abrdns[.]com
ru[.]megotron228[.]abrdns[.]com
serv2[.]soon[.]it
spum[.]port0[.]org
tango[.]strangled[.]net
te[.]n2k7[.]ru
warkelen[.]mooo[.]com
web[.]nectude[.]com
xedosss[.]89[.]fvds[.]ru

Methodology and limitations

• What we verified (14 July 2026): the lure's Cloudflare fronting by DNS; the atob() redirect by reading stage 1's script; the second stage's cloaking by rendering it live in an isolated browser and observing the /sp/ → /lp/ polling loop and the document.write() assembly; the platform by pivoting public scan history to at least five p-<hex>.workers.dev accounts.
• What we did not do: submit any credentials, complete any form, or interact with the kit beyond loading and reading it. We did not capture the final credential page, which is session-gated.
• What is inferred, not confirmed: the exact relationship (if any) between the Workers platform and the "Enter Your SharePoint" kit; the exact fields of the gated credential page; and the classification of the 43-domain list, which is absent from ThreatFox and which we treat as unconfirmed, separate infrastructure. p-<hex>.workers.dev is Cloudflare's auto-provisioned subdomain format; we do not claim a specific deploy method.

FAQ

Is turnervault[.]net the same phishing as the "Enter Your SharePoint" page? No. They share only the SharePoint theme. turnervault[.]net is a targeted, Cloudflare-fronted lure that redirects to a cloaked Cloudflare Workers kit; "Enter Your SharePoint" is a cruder, self-hosted credential card that posts to /api/v1/authenticate. Different actors, tradecraft, and infrastructure.

Why did the second stage look "offline"? It is cloaked, not offline. The workers.dev URL returns a loader that only renders the credential page for a valid victim session and loops on "Loading…" for everyone else, so scanners and sandboxes record it as blank.

Can you just block workers.dev? No. It hosts a large amount of legitimate content, so blocking the parent domain causes collateral damage. Detection has to work on the loader behaviour and per-URL indicators, and takedown has to go to Cloudflare as the host.

Does MFA stop this? Phishing-resistant MFA does. These are plain credential-capture pages rather than real-time relays, so passkeys or FIDO2 security keys defeat them; a stolen password alone is not enough to sign in.

How do we report Cloudflare Workers phishing? Through Cloudflare's abuse form with the exact URL and evidence, since Cloudflare hosts Workers content directly. Automated reporting is currently limited by the abuse-report API returning 401 for many reporters, which we cover in our Cloudflare Drop analysis.

---

About the authors

PhishEye Threat Research is the anti-phishing and digital-risk-protection team behind PhishEye, a platform for typosquat and impersonation monitoring and automated takedown. We run daily threat hunting across passive DNS, Certificate Transparency, and scan telemetry, and operate the abuse-reporting pipeline that files takedowns with hosts and registrars.

Have a correction, a related workers.dev phishing URL, or a lure to investigate? Contact the team at [email protected]. Indicators here are defanged and provided for defensive use only.