An Attacker Flipped Our Cloudflare Account in 9 Seconds — Here’s the Campaign Behind It

By Islam Ashraf — founder, PyramidBITS. I run incident response at PyramidBITS; this is the first-hand account of our own Cloudflare compromise, not a secondhand writeup.

Published August 13, 2026 · Updated August 14, 2026.

On August 12, 2026, our marketing manager told us the website had been down for two hours. I stopped the ads and opened the dashboard, already knowing the last backup was months old. What I found was quieter than a disaster:

Someone had logged into the PyramidBITS Cloudflare account with a credential that was never theirs, and in nine seconds planted catch-all 301 redirect rules — “BotFix” and “Hello World” — pointing every visitor at fake “Cloudflare verification” pages. Our servers were never touched. We are victim #9 in a four-week wave of identical Cloudflare account takeovers (ATO): stolen credentials, hijacked dashboards, visitor traffic redirected to ClickFix payload pages.

TL;DR: PyramidBITS, August 12, 2026 — Cloudflare account takeover. One stolen credential, nine seconds, catch-all 301 redirects to ClickFix verification pages. We are victim #9; 8+ public cases in 4 weeks, same playbook. Check your account: the checklist below.

The Message That Started It

“Our website is down. It’s been down for two hours.”

That was the marketing manager. I stopped the ads before I even opened the dashboard.

The dead traffic wasn’t the worst part of that message. The worst part was what I knew without checking anything: the last full backup of our systems was months old. If this was an attack — if the site was gone, not just down — we weren’t restoring anything. We were starting over.

So I opened the Cloudflare dashboard expecting the worst.

What I found was quieter than that.

The Day the Light Switch Flipped

August 12, 2026. 10:17 UTC.

Someone had logged into our Cloudflare dashboard from a consumer connection in Vietnam. Not a team member. Not a contractor. An attacker with a credential that was never theirs.

The takeover took nine seconds.

In those nine seconds:

• A catch-all redirect rule named “BotFix” appeared.
• A second rule named “Hello World” appeared next to it.
• Every request — every path, every page — began answering with a 301 to verified-project.com and get-access.to.

Expression: true. The most aggressive match Cloudflare lets you write.

Then the attacker left. No password change. No email change. No ransom note. No noise.

Two rules. Four zones. Nine seconds. Our traffic became a distribution channel for fake “Cloudflare human verification” pages.

The server was never touched.

No malware. No backdoor. No modified files. Hosting forensics came back clean. Backups clean. Diff-tools clean. Nothing to find, because nothing lived there.

The redirect answered at Cloudflare’s edge — before any request ever reached our origin.

Let’s be honest about what this was: we were not targeted by a sophisticated APT. We were a routine victim of credential hygiene failure — a textbook account takeover (ATO). The attacker didn’t break anything clever. They logged in with a credential that was already compromised somewhere else — the exact vector, stuffed password or relayed session or stolen cookie, is still being confirmed. It was enough.

Why Edge Redirect Is the Perfect Crime

An attacker with your Cloudflare account doesn’t need your server. They don’t need your hosting panel. They don’t need your code.

They need one thing: a rule that answers before your server does.

When a redirect rule matches, the response comes from Cloudflare’s edge — Server: cloudflare, generic edge body, no cache header — and your origin never sees the request.

That is the whole trick.

• No malware on the server. Nothing for hosting scanners to flag.
• No file changes. Nothing for backup comparisons or diff-tools to catch.
• No signal anywhere your usual monitoring looks.

Detection requires checking zone configuration and audit logs — the only place the attack lives, and the one place you probably never look.

Your server monitoring is a tripwire in the wrong room. The attacker never entered it.

We Are Victim #9: A Wave of Cloudflare Account Takeovers

Here’s what changed when we looked past our own dashboard.

Between July 17 and August 12, 2026 — four weeks — eight public cases of identical Cloudflare account takeovers appeared on Cloudflare Community. Same core pattern every time: stolen credentials, config changed, visitor traffic redirected to attacker sites.

#	Date (2026)	Victim	What the attacker did
1	Jul 17	nakamuraservice.com — Cloudflare Registrar	Password changed from 157.85.211.143. DNS, including MX, modified. Owner locked out of reset emails.
2	Aug 1	Unnamed account	Login from 45.128.99.35. DNS repointed to a betting site. Password and account email changed.
3	Aug 2	faisalrv.com — Cloudflare Registrar	Password changed from the same 45.128.99.35, the next day. Domain moved out of the account entirely. Live redirect to clutchslots.com — betting.
4	Jul–Aug	Multi-domain account	API login with stolen credentials. WAF rules deleted. Redirect 301 → verificator.cc/verify?d=. API tokens minted for persistence.
5	Jul–Aug	Multi-domain account	“All my domains redirected to verificator.cc.” Account access lost.
6	Aug	projetnational.org	Account compromised. Domain redirecting to phishing.
7	Aug	gouge.cc.cd	Email and password changed by the attacker.
8	Aug	checasa.com.br	Account access lost. Site flagged for phishing redirect.

Add ours, and we’re victim #9 in the visible slice. The true count is higher — forums only capture those who post.

Read the cluster, and the pattern gets sharper.

• Same IP, consecutive days: cases #2 and #3 both came from 45.128.99.35. Same actor, or the same batch of credentials. Betting flavor.
• Same backend, two accounts: cases #4 and #5 both fed verificator.cc. Multiple compromised Cloudflare accounts, one phishing operation.
• Name-pattern siblings: our payload domains — verified-project.com (registered July 20, NICENIC) and get-access.to (registered July 20–23, NameSilo) — sit in the same “verify / access” naming family as verificator.cc. Same campaign-prep window as the rest of the wave.

One attribution caution, before we go further: this is not one actor.

Different IPs. Different payload domains. Identical playbook. That combination points to multiple affiliates executing a shared, productized playbook — kits and credentials bought on the same market — not a single operator. It matters for honesty, and it matters for defense: the playbook is shared, so the defense is the same no matter whose hands are on it.

Two monetization flavors run through the cluster:

Flavor A — loud: full account seizure. Password changed. Account email changed. DNS repointed to betting and scam sites — clutchslots.com in one case. Sometimes the domain moves out of the account entirely, and the owner’s reset emails die. Traffic resale. Gambling affiliate money. Sometimes outright domain theft.

Flavor B — quiet: rule-only injection. Ours. Account ownership untouched. Only rules. Camouflage names that look like platform features — “BotFix” — or default tutorial names: “Hello World” is literally the example name from Cloudflare’s own redirect-rule docs. The owner sees nothing. The server sees nothing. Only the visitors see something, and by then they’re on the payload page.

The payload pages are ClickFix: fake “Cloudflare verification” screens that instruct the visitor to press Win+R, paste a command, press Enter. One paste. PowerShell runs. An infostealer or RAT installs. Lumma, StealC, Amatera, AsyncRAT, and HijackLoader are the families MalwareTips documented in this wave.

The loop is self-sustaining. Today’s redirect victims get infostealers on their machines. Tomorrow, those stolen sessions and passwords become the credentials used to hijack the next Cloudflare accounts. Today’s victims produce tomorrow’s attackers’ accounts.

Operators route through compromised legitimate sites so their backends never appear in scans. Our wave applies the same philosophy at the edge: the victim’s own hijacked zone is the disposable redirector — free, trusted, burned at no cost.

That disposability pattern is documented — the receipts are public. Our wave shows the same philosophy at the edge.

Cloaking is standard. Payload pages gate by geography, user-agent, referrer. Scanners get a 403 or a parked page. Our own payload — get-access.to — answered exactly that way: a clean 403 to anyone who wasn’t the intended visitor.

Redirect layers are disposable by design. In August 2026, KnowBe4’s threat report documented a “Bulletproof” blind-redirector kit: operators route exclusively through compromised legitimate sites — /.bulletproof/go.php?c=<token>, a bp_redir_sess cookie — so the AiTM backends (Sneaky2FA, Tycoon2FA) never appear in emails or scans. Caution: that kit is not confirmed in our wave. It’s context for how the layer works — and why takedowns of individual domains change nothing.

The adjacent Cloudflare surface is under the same abuse. AiTM pages hosted on Workers and Pages — a steady migration documented through July 2026. Cloudflare Drop, instant anonymous *.workers.dev hosting, was abused within hours of its July 8 launch. Quick Tunnels and cloudflared run ephemeral C2 and staging — seen in a fake Adobe/Zoom update campaign in August 2026.

The pattern behind the pattern: the redirect layer is free and disposable. You defend at the account layer, not the domain layer.

Why Free-Tier Accounts Are Soft Targets

This is not a PyramidBITS problem. It’s a structural problem with how small businesses use Cloudflare.

Cloudflare’s own 2026 Threat Report: 63% of logins they observe use credentials already compromised elsewhere. 94% of login attempts come from bots. Session-token theft is neutralizing MFA as a matter of routine.

According to APWG/Fortra’s Q1 2026 phishing activity report, 39% of phishing sites hide behind Cloudflare’s proxy — far ahead of Amazon (11%), Hostinger (4%), and Microsoft (4%). Blanket-blocking is impossible. Takedown is slow. Your brand’s valid Universal SSL certificate is laundering their operation.

And the free-tier account profile is exactly what attackers want:

• No 2FA.
• Reused passwords.
• Shared team logins.
• Global API Keys pasted into n8n scripts and automation.

One credential controls every zone on the account. Ours controlled four. The attacker used all four in nine seconds.

How do the credentials actually get taken? Ranked by prevalence in current reporting — the first three map directly onto this wave; the rest are adjacent or emerging, and relevant to any Cloudflare account owner.

1. Credential stuffing / breach reuse. Cloudflare’s own number: 63% of observed logins use credentials already compromised elsewhere. Free-tier accounts without 2FA fall first. Our working hypothesis for our own case — still being confirmed.
2. AiTM phishing, sold as a service. Evilginx-class relay kits — Tycoon2FA, Sneaky2FA, EvilProxy, NakedPages, Kratos. They sit between you and Cloudflare, relay your real login including your 2FA code, and steal the session cookie.

Tycoon2FA alone drove 13 million+ phishing emails in October 2025; Microsoft documented the campaign before its disruption pushed the kit off Cloudflare onto Russian infrastructure. Kroll’s breach-response data: 90% of breached organizations had MFA on — TOTP does not stop relay. 3. Infostealers on admin machines. Lumma, RedLine, StealC harvest cookies and saved passwords. Pass-the-cookie: the attacker logs in with no login event at all. Delivery mechanism of choice: ClickFix pages — the exact payload this wave’s redirects serve. The wave feeds its own entry vector. 4. Vishing → AiTM. Phone calls walk an employee through a fake SSO login. The tracked operator in this space — UNC6671 in the ShinyHunters ecosystem — fingerprints itself with Cloudflare hosting and NICENIC-registered domains. The same registrar that registered our payload domain. 5. Leaked API tokens / the Global API Key. Tokens sitting in n8n workflows, CI pipelines, repos. In case #4 of this wave, the attacker came in via API with stolen credentials and minted new tokens for persistence. No dashboard clicks. No UI. Pure API. 6. Emerging: GhostJacking. Poisoned telemetry that AI agents consume — the agent itself makes the malicious change. Demonstrated against Cloudflare’s recommended configuration — 9 out of 10 success in the DEF CON 34 research. If your agents read your logs, treat the content as untrusted input. Full defense in the checklist below.

Which one hit us? Still being confirmed. The defense is the same for all six — and the checklist below is the defense.

And if your domain sits on Cloudflare Registrar, the takeover can escalate beyond traffic theft. In this wave, case #3 lost the domain itself — moved out of the account, redirecting to betting. The victim’s audit log came back empty — the domain had moved accounts.

How to Tell If Your Cloudflare Account Is Compromised

We found ours because we knew where the attack lives: the Cloudflare account, not the server. This is the exact walkthrough we ran — the external fingerprints first, then the dashboard artifacts, then the full playbook of what an attacker touches.

Part 1 — The External Fingerprint: How to Detect an Edge Redirect

You can spot an edge-redirect hijack from outside, before you even log in. Three tests:

1. Inspect the 301. Fetch your homepage and read the headers. You’re looking for three tells:

   • An HTTP 301 with Server: cloudflare.
   • The generic 167-byte Cloudflare edge body — not your server’s HTML, not your CMS’s 404 page.
   • No CF-Cache-Status header — your origin never saw this request.

2. Try paths that shouldn’t exist. The hijack is a catch-all. Fetch a random path that has never existed on your site — and your admin login path too. Both answer 301 to the same destination. Your web server has no rules for paths that don’t exist, so this isn’t your server. Cache-busters don’t help: append a query string, fetch again, same 301. That’s a rule answering, not a cache.

3. Bypass the edge — hit the origin IP directly. Curl your origin IP with your domain’s Host header. You get only the behavior your server was always configured for: benign canonicalization — the normal redirects your server has always served. No redirect to any verification domain. That’s the proof: the redirect sits above your server, at the edge. The attacker never touched the origin, because the rule never lived there.

If all three line up, stop looking at your server. Look at the account.

Part 2 — The Dashboard Artifacts: Read Your Cloudflare Audit Log First

The external tests tell you it’s at the edge. The dashboard tells you what happened — this is exactly how we reconstructed our attack:

1. Start with the Audit Log. Account → Audit Logs. Export the CSV — don’t just eyeball the screen. Filter on rulesets.create/update — the event class behind every rule change. Filter on “Create zone rule”. Filter on LOGIN events. For each hit, capture: the interface (ui or api), the source IP, the CF-RAY, the actor email, and the rule JSON — the kind (http_request_dynamic_redirect), the expression (true), and the destination. That one export is the whole attack: who logged in, what they created, where it pointed.

2. Review every token. My Profile → API Tokens, then Account API Tokens. Look at the “Last used” timestamps. A token you didn’t create — or a timestamp you don’t recognize — is persistence. Case #4 in the wave worked exactly this way: tokens minted so access survives a password reset.

3. Review every session. My Profile → Sessions. Revoke anything you don’t recognize.

4. Diff every zone. Redirect Rules, Page Rules, Bulk Redirects, Transform Rules, Workers routes, DNS records, Email Routing, SSL mode, security level. If you didn’t set it, question it. Our entire attack was two rows in one of these lists.

5. Push the logs out before you’re locked out. Set up Logpush to external storage. Cloudflare’s compromised-account docs recommend it: after an account seizure, the in-dashboard log can be incomplete — or empty. Case #3’s was: the domain had moved to a different account. If your evidence lives only inside the account an attacker can seize, you have no evidence.

The five steps above are the whole forensic pass: login → rules → tokens → sessions → zones.

Part 3 — What Cloudflare Attackers Touch: The Full Playbook

The full playbook, condensed: what a Cloudflare attacker can weaponize, what the wave does with it, and what we found in ours.

Artifact	Malicious use	In the wave	Our account
Redirect Rules (http_request_dynamic_redirect)	Catch-all 301 to a payload domain	✅ Primary — cases #4, #5, #9	✅ “BotFix” and “Hello World”
DNS records	Repoint A/MX to attacker infrastructure or betting	✅ Cases #1–3	❌ Untampered
Account email + password	Owner lockout	✅ Flavor A	❌ Attacker stayed quiet
WAF / custom rules	Deleted to weaken posture	✅ Case #4	❌
API tokens	Persistence past password reset	✅ Case #4	❌ None found — verify visually
Registrar transfer / zone removal	Domain theft	✅ Case #3	❌
Page Rules / Bulk Redirects / Workers / Email Routing	Alternate redirect paths, mail interception	Plausible	❌ Not observed — verified during response
Security level / SSL mode	Downgrade	—	⚠️ Not the attacker — we’d left SSL mode essentially_off. Restore it.

Read the names before you dismiss anything: “BotFix” sounds like a platform feature, and “Hello World” is literally the example name from Cloudflare’s own redirect-rule docs. Camouflage is the convention.

Ours was the quiet flavor — exactly one checkmark in that table: Redirect Rules, and nothing else. That’s why the server forensics came back clean: nothing ever lived there. Check the rules first. The checklist below is this walkthrough, turned into a habit.

The Cloudflare Security Checklist: Boring Habits That Actually Stop This

Nothing in this section is exotic. That’s the point. These are the habits we now run — and the habits you should run before someone else does. It’s the same logic as Gate 4 in our AI cost framework: security is a daily habit, not a one-time setup.

1. FIDO2/passkeys, not TOTP

TOTP codes can be relayed. Adversary-in-the-middle phishing sits between you and Cloudflare, captures your six-digit code and your session cookie in real time, and replays them. Passkeys are bound to your device. They survive relay. That’s the only MFA class that does.

2. Treat your email account as part of the Cloudflare perimeter

Password resets flow through it. Mailbox access is Cloudflare access. If your email has weak security, your Cloudflare security is theater.

3. Kill the Global API Key in automation

A Global API Key is a master switch for every zone. If it’s sitting in an n8n workflow or a script, it’s a credential awaiting theft. Replace it with scoped API tokens — least privilege per zone, restricted to specific source IPs.

4. Alert on audit events — and export the logs

Rule creation. Member changes. Logins from new countries or networks (ASNs). Cloudflare’s own docs recommend pushing audit logs to external storage, because after an account seizure the in-dashboard log can be empty. Case #3’s was. If your evidence lives only in the attacker’s reach, you have no evidence. Set both up from the dashboard while it’s still yours: Notifications for audit events — rule creation, member changes, logins from a new ASN or country — and Logpush to stream the audit log to storage you control.

5. The zone-diff habit

Five minutes, periodically: redirect rules, page rules, bulk rules, Workers routes, DNS records, SSL mode, security level. This is exactly where our attack lived. Check the config, not just the uptime.

6. AI-agent hygiene — new for 2026

GhostJacking, disclosed at DEF CON 34 in August 2026: attackers poison the telemetry and logs that AI agents consume, so the agent itself makes the malicious DNS or config change. Demonstrated against Cloudflare’s recommended configuration — 9 out of 10 success. If your agent reads your logs or alerts, treat that content as untrusted input. Never let an agent auto-execute instructions found in your own monitoring. Human approval for any DNS or rule change.

FAQ: Cloudflare Account Takeover

How do I know if my Cloudflare account was hacked?

Check the audit log — the attack lives there, not on your server. Export Account → Audit Logs and filter on rulesets.create/update, “Create zone rule”, and LOGIN events: a rule you never created, or a login from an unfamiliar country or ASN, is the signal. From outside, fetch a path that has never existed on your site — if it answers 301 with Server: cloudflare, the generic 167-byte edge body, and no CF-Cache-Status header, a catch-all redirect rule is answering at the edge.

What is ClickFix?

ClickFix is the payload behind this wave: fake “Cloudflare human verification” pages that instruct the visitor to press Win+R, paste a command, and press Enter. One paste runs PowerShell, and an infostealer or RAT installs on the machine. The families documented in this wave: Lumma, StealC, Amatera, AsyncRAT, and HijackLoader.

Why did my website redirect to a verification page?

Because a catch-all redirect rule was added to your Cloudflare account — not to your server. An attacker with stolen credentials logs into the dashboard and creates a 301 rule that answers at Cloudflare’s edge, before any request reaches your origin. Every path responds with a 301 to the payload domain, so your visitors land on a fake “Cloudflare verification” page instead of your site.

The Honest Close

This is not a success story. The response is still finishing — the exact entry vector is still an open question, and the token and mailbox reviews are still running. I’m not going to tell you we’re safe, because we haven’t finished proving it.

And the campaign isn’t over. verified-project.com and get-access.to are down or cloaked now. Successor domains are a safe bet. Payload infrastructure rotates weekly, and the wave will keep producing victims. The monitoring habits above are the real fix.

Here’s the sovereignty lens, plain: the account controlling your traffic is a control surface. If you don’t own access to it, you own nothing.

Have You Seen This Attack?

If you run Cloudflare — free tier or paid, one zone or fifty — and any of this sounds familiar, I want to compare notes:

• A rule you never created, with an innocent name
• Traffic redirecting somewhere it shouldn’t

Comment below or message me. If enough of us compare notes, this wave stops being something each victim discovers alone.

My DMs are open — I’ll walk you through a 30-minute Cloudflare security audit, or send you the full checklist to run yourself. If you’d rather run it with someone watching your back, the defense protocol exists for exactly this.

Either way, run it. The attacker doesn’t need to be clever — they just need one reused credential. The next Cloudflare account takeover doesn’t have to be yours.

Appendix: Indicators from This Wave

Shared for defender awareness — and only that. These are attacker-controlled addresses, domains, and infrastructure observed in the public cases and in ours. No victim data. No internal identifiers.

Indicator	Type	Context
45.128.99.35	IPv4	Betting-flavor actor. Hit at least two victims — Aug 1 and Aug 2.
157.85.211.143	IPv4	Source of the nakamuraservice.com account seizure, Jul 17.
verificator.cc	Domain	Verification-phish backend. At least two Cloudflare ATO victims feeding it.
clutchslots.com	Domain	Betting redirect destination (the faisalrv.com case).
verified-project.com	Domain	Our payload #1. NICENIC, registered Jul 20. Now NXDOMAIN.
get-access.to	Domain	Our payload #2. NameSilo, Cloudflare-hosted. Cloaked — 403 to scanners.
2001:ee0:5502:2067:...	IPv6	Our actor. VNPT consumer connection, Ho Chi Minh City (address truncated).

How to use them: block or flag these at your DNS and edge, and hunt your Cloudflare audit logs for them. Two caveats. First, these are infrastructure, not identities — the wave runs on shared kits and shared credentials, so an address can be reused across affiliates. Second, the payload domains are already down or cloaked. Their absence from your logs is not proof of clean. Infrastructure rotates weekly. Hunt the pattern, not just the list.

Sources

Vendor and industry reporting:

• Cloudflare — 2026 Threat Report (Cloudforce One): blog.cloudflare.com/2026-threat-report
• Cloudflare Docs — Secure a compromised account: developers.cloudflare.com/…/secure-a-compromised-account
• Microsoft Security Blog — Q2 2026 email threat landscape; Tycoon2FA disruption (2026-07-23)
• KnowBe4 Threat Lab — “Bulletproof” blind-redirector kit (2026-08-10)
• PhishEye / APWG — Q1 2026 phishing takedown data (2026)
• The Hacker News — UNC6671 vishing-to-AiTM SaaS theft (2026-08-07)
• MalwareTips — fake Cloudflare human-verification / ClickFix mechanics (2026-08-08)
• CyberPress / Dark Reading — GhostJacking: AI-agent telemetry poisoning (2026-08-10/11)
• PhishFort — Cloudflare Drop anonymous-hosting abuse (2026-07)
• Securelist — cloud platforms in phishing, Aug 2025–Jul 2026 dataset

Primary victim reports — Cloudflare Community (Jul–Aug 2026): threads #940886, #944962, #944975, #945826, #943214, #946165, #946219, #944277. Our incident (2026-08-12) is the ninth case in this visible cluster.

All sources accessed August 13–14, 2026.