- Joined
- Dec 30, 2024
- Messages
- 396
- Reaction score
- 208
- Points
- 62
- Website
- blackhatpakistan.net
- Points
- 1,108
- USD
- 1,108
Bypassing Cloudflare means reaching the origin server behind its proxy layer - finding where the real host lives, or arriving with traffic that passes its filters - because Cloudflare terminates every request at the edge: DNS resolves to CF anycast, TLS terminates there, and the origin only ever talks to Cloudflare's own addresses. There are two independent problems dressed as one: find the origin IP (OSINT), and look like traffic the edge accepts (client fingerprinting). Most successful "bypasses" are one of those two, not some clever header trick.
TL;DR - Origin discovery: certificate transparency, historical DNS, mail records, and leaked subdomains beat any request manipulation. Edge passing: modern bot management scores TLS and HTTP fingerprints (JA3/JA4, header order, HTTP/2 settings) before content, so browser-impersonating clients matter more than User-Agent strings. The origin, when found, is usually reachable directly with correct Host/SNI - because direct access was never hardened, the assumption was "everything goes through CF."
PROBLEM 1 - FINDING THE ORIGIN
- Certificate transparency logs (crt.sh, Censys) - every TLS cert ever issued for the domain, including ones pointing at the bare origin IP before CF was added or on a forgotten subdomain.
- Historical DNS (DNSDumpster, SecurityTrails, PassiveTotal) - A records from before the migration, still live and often still serving.
- Mail infrastructure - MX, SPF, and DMARC records routinely point at servers outside the proxy (mail servers rarely sit behind CF), and shared hosting fingerprints connect them back.
- Subdomain sprawl - staging, dev, direct-connect, vpn, and api-host records frequently predate the CDN cutover and never got moved.
- Service-specific leaks - webmail, cpanel, phpmyadmin, and git panels on ports CF does not proxy (CF proxies HTTP/S only - anything on 22, 3306, 8080-adjacent alt ports, or non-standard services is inherently direct).
- Shodan/Censys host search - banners hosting the same unique string, favicon hash, or page title as the target, filtered by org/ASN.
Testing a candidate origin needs Host and SNI set to the real domain (the origin serves virtual hosts, and its certificate only matches the true name). A 200 with the real application versus CF's error page confirms it; a timeout means the firewall only accepts CF ranges.
PROBLEM 2 - LOOKING LIKE A REAL CLIENT
The edge decides long before any WAF rule on payload: TLS handshake fingerprint (JA3/JA4 - cipher list, extensions, their order - unique per client implementation), HTTP/2 frame settings and priority tree, header order and casing, and behavioral signals (JS challenge execution, cookie continuity, request cadence). A script with Go's TLS stack and curl's header order is classified by stack, not by the User-Agent it claims.
- Impersonating clients - curl-impersonate, tls-client, and similar libraries reproduce a real browser's TLS and HTTP/2 fingerprints; the UA string then matches because it was copied along with the fingerprint.
- Real browser automation - headless browsers with realistic fingerprints execute the JS challenge and pass Turnstile as themselves; detected automation flags (webdriver flags, missing plugins) are what usually fail, not the automation itself.
- Cached vs uncached paths - static, cache-friendly URLs sometimes answer at lower scrutiny than dynamic POST endpoints; useful for content retrieval, irrelevant for anything stateful.
- Rate shaping - probing slowly on paths that expect traffic (homepage pacing) versus hammering login endpoints (instant score spike). The bot score is per-IP, per-behavior, and cumulative.
*Bypass the fingerprint and you still face the challenge; solve the challenge with a burned fingerprint and you are back at square one. Both halves or nothing.*
PROBLEM 3 - THE CHALLENGES THEMSELVES
JS challenges execute CF's script and set clearance cookies - solved by anything that runs real JS. Turnstile is the CAPTCHA-class widget - solved interactively, by accessibility routes where configured, or by solver services (captcha farms cost per solve and have their own operational footprint). Managed challenges vary the difficulty with risk score: a clean, consistent, browser-grade client gets the easy path; a flagged one gets escalating friction. None of these are cryptographic problems - they are cost problems, which is exactly why the ecosystem around them is a market.
WHY ORIGINS FALL AFTER DISCOVERY
The proxy was the firewall. Origins reachable directly typically have: expired or hostname-mismatched certificates (nobody renewed the origin cert - it was never presented), no rate limiting (that lived at the edge), no WAF (same), and admin panels bound to 0.0.0.0 with the logic "CF protects this." The correct engineering response on the other side is an origin firewall accepting only published CF ranges, authenticated origin pulls, and treating the CDN as a cache - not as a security boundary.
FAQ
Q: Does changing User-Agent bypass Cloudflare?
A: It changes one low-weight signal. TLS fingerprint, HTTP/2 fingerprint, and behavior determine classification; UA is cosmetic unless it contradicts the fingerprint (claims Chrome, has a Go TLS stack).
Q: Is bypassing Cloudflare legal?
A: Reaching your own or explicitly authorized infrastructure through its own CDN configuration is normal operations and testing. Accessing systems you are not authorized to touch is the line, with or without a proxy in between - the proxy changes nothing about authorization.
Q: What if the origin is firewalled to CF ranges only?
A: Then origin discovery is step one anyway - because the failure mode shifts to misissued certificates, other subdomains, mail hosts, and non-HTTP services sharing the same IP. Range-locking the origin is the fix for direct access, not for CT-log leakage of the address itself.
Q: How do defenders detect origin-IP exposure?
A: Watch CT logs for your own domains (new cert mentioning an origin hostname), scan your own address space for hosts serving your site's unique content outside CF, and alert on direct-to-origin hits in web logs - the access log line that does NOT come from a CF range is the finding.
RELATED ON BLACKHAT PAKISTAN
OSINT Tools for Beginners - the enumeration toolkit behind every origin-discovery method here.
Nmap Cheat Sheet 2026 - scanning exposed services on candidate origins.
DDoS Attack Basics - what the proxy layer absorbs when it is configured as one.
SQL Injection Tutorial - testing dynamic endpoints once a direct path exists.
TL;DR - Origin discovery: certificate transparency, historical DNS, mail records, and leaked subdomains beat any request manipulation. Edge passing: modern bot management scores TLS and HTTP fingerprints (JA3/JA4, header order, HTTP/2 settings) before content, so browser-impersonating clients matter more than User-Agent strings. The origin, when found, is usually reachable directly with correct Host/SNI - because direct access was never hardened, the assumption was "everything goes through CF."
PROBLEM 1 - FINDING THE ORIGIN
- Certificate transparency logs (crt.sh, Censys) - every TLS cert ever issued for the domain, including ones pointing at the bare origin IP before CF was added or on a forgotten subdomain.
- Historical DNS (DNSDumpster, SecurityTrails, PassiveTotal) - A records from before the migration, still live and often still serving.
- Mail infrastructure - MX, SPF, and DMARC records routinely point at servers outside the proxy (mail servers rarely sit behind CF), and shared hosting fingerprints connect them back.
- Subdomain sprawl - staging, dev, direct-connect, vpn, and api-host records frequently predate the CDN cutover and never got moved.
- Service-specific leaks - webmail, cpanel, phpmyadmin, and git panels on ports CF does not proxy (CF proxies HTTP/S only - anything on 22, 3306, 8080-adjacent alt ports, or non-standard services is inherently direct).
- Shodan/Censys host search - banners hosting the same unique string, favicon hash, or page title as the target, filtered by org/ASN.
Code:
dig MX target.tld; dig TXT target.tld mail path that bypasses the proxy
curl --resolve target.tld:443:ORIGIN_IP https://target.tld/ test with correct SNI + HostTesting a candidate origin needs Host and SNI set to the real domain (the origin serves virtual hosts, and its certificate only matches the true name). A 200 with the real application versus CF's error page confirms it; a timeout means the firewall only accepts CF ranges.
PROBLEM 2 - LOOKING LIKE A REAL CLIENT
The edge decides long before any WAF rule on payload: TLS handshake fingerprint (JA3/JA4 - cipher list, extensions, their order - unique per client implementation), HTTP/2 frame settings and priority tree, header order and casing, and behavioral signals (JS challenge execution, cookie continuity, request cadence). A script with Go's TLS stack and curl's header order is classified by stack, not by the User-Agent it claims.
- Impersonating clients - curl-impersonate, tls-client, and similar libraries reproduce a real browser's TLS and HTTP/2 fingerprints; the UA string then matches because it was copied along with the fingerprint.
- Real browser automation - headless browsers with realistic fingerprints execute the JS challenge and pass Turnstile as themselves; detected automation flags (webdriver flags, missing plugins) are what usually fail, not the automation itself.
- Cached vs uncached paths - static, cache-friendly URLs sometimes answer at lower scrutiny than dynamic POST endpoints; useful for content retrieval, irrelevant for anything stateful.
- Rate shaping - probing slowly on paths that expect traffic (homepage pacing) versus hammering login endpoints (instant score spike). The bot score is per-IP, per-behavior, and cumulative.
*Bypass the fingerprint and you still face the challenge; solve the challenge with a burned fingerprint and you are back at square one. Both halves or nothing.*
PROBLEM 3 - THE CHALLENGES THEMSELVES
JS challenges execute CF's script and set clearance cookies - solved by anything that runs real JS. Turnstile is the CAPTCHA-class widget - solved interactively, by accessibility routes where configured, or by solver services (captcha farms cost per solve and have their own operational footprint). Managed challenges vary the difficulty with risk score: a clean, consistent, browser-grade client gets the easy path; a flagged one gets escalating friction. None of these are cryptographic problems - they are cost problems, which is exactly why the ecosystem around them is a market.
WHY ORIGINS FALL AFTER DISCOVERY
The proxy was the firewall. Origins reachable directly typically have: expired or hostname-mismatched certificates (nobody renewed the origin cert - it was never presented), no rate limiting (that lived at the edge), no WAF (same), and admin panels bound to 0.0.0.0 with the logic "CF protects this." The correct engineering response on the other side is an origin firewall accepting only published CF ranges, authenticated origin pulls, and treating the CDN as a cache - not as a security boundary.
FAQ
Q: Does changing User-Agent bypass Cloudflare?
A: It changes one low-weight signal. TLS fingerprint, HTTP/2 fingerprint, and behavior determine classification; UA is cosmetic unless it contradicts the fingerprint (claims Chrome, has a Go TLS stack).
Q: Is bypassing Cloudflare legal?
A: Reaching your own or explicitly authorized infrastructure through its own CDN configuration is normal operations and testing. Accessing systems you are not authorized to touch is the line, with or without a proxy in between - the proxy changes nothing about authorization.
Q: What if the origin is firewalled to CF ranges only?
A: Then origin discovery is step one anyway - because the failure mode shifts to misissued certificates, other subdomains, mail hosts, and non-HTTP services sharing the same IP. Range-locking the origin is the fix for direct access, not for CT-log leakage of the address itself.
Q: How do defenders detect origin-IP exposure?
A: Watch CT logs for your own domains (new cert mentioning an origin hostname), scan your own address space for hosts serving your site's unique content outside CF, and alert on direct-to-origin hits in web logs - the access log line that does NOT come from a CF range is the finding.
RELATED ON BLACKHAT PAKISTAN
OSINT Tools for Beginners - the enumeration toolkit behind every origin-discovery method here.
Nmap Cheat Sheet 2026 - scanning exposed services on candidate origins.
DDoS Attack Basics - what the proxy layer absorbs when it is configured as one.
SQL Injection Tutorial - testing dynamic endpoints once a direct path exists.
Last edited:
