Broken Phishing URLs Are Bypassing Your Filters

A wave of phishing emails is using deliberately malformed URL parameters to slip past security tools — and the technique works because browsers simply don't care about the garbage characters.

SANS Internet Storm Center handler Xavier Mertens published a diary entry on February 5 documenting the campaign, which relies on broken query string syntax that most URL parsers and regex-based detectors can't cleanly handle. The URLs still load fine in any modern browser, making them an effective evasion layer that costs attackers nothing to implement.

How the Trick Works

Standard URL parameters follow a predictable format: a question mark kicks off the query string, followed by name=value pairs separated by ampersands. Security tools — from email gateways to SIEM correlation rules — depend on this structure to extract indicators of compromise, classify URLs, and match against blocklists.

The phishing emails Mertens observed append gibberish after a trailing ampersand. Instead of a legitimate second parameter, the URLs end with strings like &*(Df, &*(chgd, &*(TemP, and &*(lIi. These are syntactically invalid. No web server would interpret them as meaningful parameters.

But that's the point. As Mertens puts it, the broken parameters serve to "break security controls" — specifically regex-based detection, URL normalization routines, and IOC extraction pipelines. A regex expecting &key=value patterns will choke on &*(Df. A normalizer that strips or rewrites query strings might silently drop the URL entirely, preventing it from reaching a threat feed. And IOC extraction tools that split on ampersands will produce junk entries that don't match any known indicator.

Browsers, on the other hand, just ignore what they can't parse and load the page anyway.

Cloudflare Workers as Phishing Infrastructure

The campaign infrastructure leans heavily on Cloudflare Workers subdomains. Mertens listed several observed domains including cooha0720.7407cyan.workers.dev, calcec7.61minimal.workers.dev, and shiny-lab-a6ef.tcvtxt.workers.dev, alongside at least one Netlify-hosted domain.

This isn't a new pattern. Fortra reported that phishing abuse of Cloudflare Workers domains jumped 104% from 2023 to 2024, reaching nearly 5,000 incidents. The appeal is obvious: workers.dev domains inherit Cloudflare's reputation, they're free to spin up, and they provide built-in SSL and CDN performance. For a phishing operator, that's a disposable, trusted-looking host with zero upfront cost.

We've seen this infrastructure abuse before in campaigns like the Google Cloud Application Integration attack that targeted 3,200 organizations by sending phishing emails through Google's own servers. Attackers keep gravitating toward cloud platforms because the domains carry implicit trust that traditional blocklist approaches struggle with.

What the Emails Look Like

The phishing lures themselves aren't sophisticated. Targets receive messages asking them to open shared documents or verify pending emails — standard credential harvesting pretexts. Each URL embeds the target's email address as a parameter (in this case, [email protected]), likely for tracking which victims click and for pre-filling fake login forms.

The combination of a recognizable cloud domain, a personalized URL parameter, and the broken trailing characters creates a three-layer problem for defenders. The cloud domain bypasses reputation filters. The email parameter adds social engineering credibility. And the malformed syntax disrupts automated analysis.

This approach echoes other phishing campaigns abusing legitimate platforms, where attackers used Google Slides' publish feature to host credential-harvesting pages. The common thread is using trusted services as a shield against detection.

Why This Matters for Detection Teams

Regex-based URL matching remains a backbone of email security. Secure email gateways, sandbox detonation triggers, and SOAR playbooks all parse URLs to decide what to block, detonate, or investigate. A URL that doesn't conform to expected syntax can fail silently in any of these systems — not triggering a block, not being extracted for analysis, not matching a YARA rule or Sigma detection.

Mertens recommends building regex patterns that specifically extract the final malformed parameter, but the broader lesson is that URL parsing in security tools needs to handle adversarial input the same way browsers do: permissively. If Chrome will load it, your gateway needs to evaluate it.

This isn't purely academic. The XWorm steganography campaign that SANS documented just yesterday showed similar creativity in bypassing automated analysis — hiding payloads inside PNG images where scanners wouldn't look. Attackers are consistently probing the gaps between what security tools parse and what endpoints actually execute.

Defensive Recommendations

Organizations should audit their URL parsing logic across the detection stack. Specific steps worth taking:

1. Test your email gateway with deliberately malformed URLs. Send test messages containing &*( syntax and verify they're still detonated and classified.
2. Review regex patterns in SIEM rules and SOAR playbooks. Patterns that assume well-formed query strings will miss these variants.
3. Block or flag workers.dev subdomains that don't match known business use. If your organization uses Cloudflare Workers internally, build an allowlist rather than relying on the domain's reputation.
4. Extract URLs permissively. IOC extraction should grab the full URL string before attempting to parse parameters, not after.
5. Monitor for cloud-hosted phishing using services like Cloudflare's abuse reporting to flag malicious Workers deployments.

The broken URL technique is cheap, effective, and trivially reproducible. Any phishing kit can append random characters to a query string. The question for defenders is whether their tools are robust enough to handle URLs that don't play by the rules — because browsers certainly are.