When one Cloudflare token reroutes your DNS and kills your WAF

A Cloudflare API token controls both where your DNS points and whether your edge protection is on. A stolen token can reroute login traffic and strip the WAF at the same time, so the damage is twofold.

How the attack works

The token authenticates from an unfamiliar source over the API, then changes a proxied login record to point at attacker infrastructure, sending real user traffic through a host the attacker controls. Minutes later it disables the WAF managed rules and a custom firewall rule, exposing the origin and removing detection. Users hitting the login page now transit attacker infrastructure for credential capture while the unshielded origin gets probed directly. The malicious signal is one token from a never-seen source repointing a proxied record off platform and disabling protective rules in the same short window. In ATT&CK terms this is T1098, Account Manipulation, paired with T1562, Impair Defenses.

Why it works

The token was account wide and unrestricted, with edit on both DNS and firewall settings and no source restriction, and DNS and WAF changes were not alerted. Each change type is normal in isolation, so nothing fired on the pairing.

How to fix it

The acting identity is a token, so roll it. Resetting the account owner password does nothing to a standalone token, and blocking the source while the token lives lets the attacker edit again from elsewhere. Then restore two things: revert the DNS record to its known-good value and re-enable the WAF and firewall rules. The non-obvious point is that reverting DNS does not undo the interception window that already happened, so treat credentials submitted during the hijack as compromised. Long term, scope tokens to minimum zones and permissions, add source restriction and expiry, vault the secrets, and alert on every DNS and WAF change.

Practice it

We built this as a GraphLattice Range scenario so teams can rehearse the repoint, the WAF disable, and the roll-and-restore response.