IIS 8.0 Memory Disclosure & Cloudflare WAF Bypass Assessment
Exploited a critical IIS 8.0 HTTP.sys memory disclosure and proved full Cloudflare WAF bypass via exposed origin IPs.
February 2026/India/Single assessment session
StackMicrosoft IIS 8.0 (unpatched) · ASP.NET application · SQL Server backend · Cloudflare WAF · AWS EC2 (secondary replicas) · DreamHost shared hosting
The situation
A healthcare diagnostics provider ran a public-facing ASP.NET platform behind Cloudflare WAF. Early recon turned up the origin IPs for the app and several replica servers sitting right there in DNS, which made the WAF basically useless. The origin servers were also on an IIS version with multiple unpatched vulnerabilities.
What I found
The headline issue was MS15-034 (CVE-2015-1635) on IIS 8.0, the HTTP.sys memory disclosure rated CVSS 9.8, and I exploited it successfully. The kernel memory that came out of it showed internal network topology (10.x.x.x/24) and application paths, enough to map the environment from outside. On top of that, the origin IP was publicly exposed in DNS, which meant Cloudflare WAF was being bypassed entirely anyway. And CVE-2014-4078 (IIS IP Restriction Bypass) was also sitting there unaddressed.
The configuration side was almost as bad. TLS 1.0 and 1.1 were still enabled (RFC 8996 deprecated them), the HTTP TRACE method was on (XST risk), and Server and X-Powered-By headers were disclosing the full technology stack to anyone who asked. Multiple unpatched servers (UAT, legacy environments) were reachable from the internet, the AWS-hosted replicas were likely vulnerable with the same application stack, and the primary server hadn't received a security update since at least 2020.
What I did
I ran the Metasploit module auxiliary/scanner/http/ms15_034_http_sys_memory_dump and it worked on the first try. I dumped kernel memory to two forensic files for the evidence package, enumerated 8 subdomains, and mapped the origin IPs through DNS reconnaissance. To prove the WAF bypass I sent HTTP requests with curl directly to the origin IP and confirmed they landed without Cloudflare in the path. TLS got analysed with openssl and a couple of external scanners, and I fingerprinted the IIS version via the /CRL/ application root binding.
How it landed
Handed over a critical-risk report with a working proof-of-concept for the IIS HTTP.sys issue. The kernel memory leak was the piece that confirmed the WAF bypass: once the origin IPs were public, Cloudflare protection was just theatre. The client got a prioritised patching roadmap, origin-hiding guidance, and a TLS hardening plan. The most useful piece, per the internal security team, was the memory-disclosure evidence, which finally got their patching change request through the approval queue.