Unveiling Hidden Preauth Vulnerabilities in Windows HTTP Services
Black Hat USA 2025 · Day 1 · Briefings
Overview
Researchers from CyberKoolun at Huazhong University of Science and Technology systematically mapped the Windows HTTP API service framework and uncovered a class of pre-authentication vulnerabilities — both logic-based denial-of-service bugs and remote code execution flaws — that affect Windows built-in HTTP services including UPnP, Remote Desktop Gateway, and the KDC Proxy. The findings include multiple CVEs and demonstrate that incorrect use of just a handful of HTTP API functions can permanently hang services or, in the right conditions, achieve RCE against unauthenticated clients. ---

Key moments
- 4:00 Windows HTTP.sys serves IIS, WinRM, RDP, and dozens of critical services
- 8:00 Bug class: thread pool exhaustion via ioResult error causes preauth DoS
- 9:59 Demo: corrupted packets drain all receive threads, timing out all HTTP requests
- 12:00 Second bug: services skip httpsendresponse causing non-paged pool exhaustion
- 14:00 Demo: BranchCache service PoC causes full kernel non-paged pool DoS
- 17:59 Systematic audit uncovers multiple Windows HTTP services with same bug pattern
- 24:00 MSRC rated preauth DoS as low severity since services assumed trusted network
- 29:59 Remediation principle: HTTP services must always re-queue receive after any request
Unveiling Hidden Preauth Vulnerabilities in Windows HTTP Services
Speakers: Kaishou (Kosho), CyberKoolun, Huazhong University of Science and Technology; Victor Yi, CyberKoolun, Huazhong University of Science and Technology
Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas
YouTube: https://www.youtube.com/watch?v=CD-1s2uBqmQ
Reading Time: ~8 minutes
Type: Briefing
TL;DR
Researchers from CyberKoolun at Huazhong University of Science and Technology systematically mapped the Windows HTTP API service framework and uncovered a class of pre-authentication vulnerabilities — both logic-based denial-of-service bugs and remote code execution flaws — that affect Windows built-in HTTP services including UPnP, Remote Desktop Gateway, and the KDC Proxy. The findings include multiple CVEs and demonstrate that incorrect use of just a handful of HTTP API functions can permanently hang services or, in the right conditions, achieve RCE against unauthenticated clients.
Introduction
Almost every Windows service that exposes an HTTP endpoint — from UPnP to Remote Desktop Gateway to the Online Certificate Status Protocol responder — is built on top of the Windows HTTP Server API (http.sys and the userland HTTP.dll). Because these services typically accept connections without requiring authentication at the receiving layer, any vulnerability in how they handle raw HTTP traffic is reachable by any unauthenticated network attacker. The surface is large: the netsh http show servicestate command enumerates every registered HTTP service on a Windows host, and the researchers used it as their primary target discovery mechanism.
Kaishou and Victor Yi set out to catalog the common programming patterns and common mistakes across this entire class of services, rather than hunting for bugs in individual targets. The result is a generalized attack methodology that produced multiple CVEs — including pre-auth denial-of-service bugs in UPnP (CVE-2025-27471) and OCSP, and a critical integer overflow leading to RCE in the KDC Proxy Service (CVE-2024-43639), as well as a use-after-free in Remote Desktop Gateway.
The Windows HTTP Service Framework
▶ Watch: HTTP Service Framework Overview (02:00)
Windows HTTP API services communicate with the kernel component http.sys via DeviceIoControl calls with specific I/O control codes. The two most critical functions in the receiving path are HttpReceiveHttpRequest (reads HTTP headers) and HttpReceiveRequestEntityBody (reads the HTTP body/POST data). Services register with HttpCreateServerSession and HttpAddUrlToUrlGroup, and the entire registration can be queried with httpQueryServiceConfig or inspected with netsh.
The researchers identified three distinct receiving architectures across Windows HTTP services:
- Synchronous single-thread receiving — one thread loops on
HttpReceiveHttpRequest. If that loop is broken, no requests are processed. - Asynchronous single-thread receiving — the thread does not block inside
HttpReceiveHttpRequestbut handles completions via overlapped I/O; a timing gap can break the loop permanently. - Asynchronous callback-based receiving — a thread pool handles multiple clients concurrently; threads must call
StartThreadPoolIoafter processing to replenish the pool, or the pool drains.
Understanding this taxonomy is what made the research systematic: the same failure mode — a function that stops issuing HttpReceiveHttpRequest — applies across all three, with different triggers.
Logic-Based DoS: Three Vulnerabilities, Three Mechanisms
▶ Watch: Synchronous DoS — CVE-2024-43512 (04:00)
CVE-2024-43512 targets the sync single-thread pattern. The vulnerable service calls HttpReceiveHttpRequest with a fixed buffer of 0x1360 bytes. When an attacker sends an HTTP header larger than this, the function returns 0xEA (ERROR_INSUFFICIENT_BUFFER). The correct response is to update the buffer length and retry; this service instead re-calls the function with the same undersized buffer, looping forever without accepting any new connections. After the vulnerability is triggered, all legitimate clients receive timeout errors.
▶ Watch: Async DoS — CVE-2025-27471 (UPnP) (06:00)
CVE-2025-27471 exploits the async single-thread pattern in the Windows UPnP service. Because HttpReceiveHttpRequest is handled asynchronously, there is a race window. When an attacker floods the service with malicious requests simultaneously, the function returns an error before GetOverlappedResult can update the byte-transfer count. The receive length is set to zero, and the service enters an infinite error loop — one that persists even after the attacker disconnects. Normal UPnP clients then get no responses.
A third variant targets the Function Resource Service using the thread-pool callback pattern. When HttpReceiveHttpRequest returns a non-zero error code (malformed packet), the service's callback returns immediately without calling StartThreadPoolIo to replenish the pool. An attacker who repeatedly sends corrupted packets drains all threads in the receive pool. Once the pool is empty, all requests time out. MSRC rated this low severity because the service is considered to run only on trusted networks — despite being accessible pre-authentication.
The researchers also discovered a response-stage DoS class: services that never call HttpSendHttpResponse or HttpCancelHttpRequest after processing certain error paths leave kernel-side connection structures allocated indefinitely, exhausting the non-paged pool and causing a system BSOD. The BranchCache service is a demonstrated example of this pattern.
IIS API Extension Reference-Count Bugs
▶ Watch: IIS OCSP DoS — CVE-2024-38067 (18:01)
Services running under IIS use an additional abstraction layer called an IIS API Extension (ISAPI), which manages a reference-counted IIS_API_CONTEXT structure. IIS caps the reference count at 0x1366; once this limit is reached, the service returns 503 Service Unavailable to all subsequent clients — permanently.
CVE-2024-38067 affects the Online Certificate Status Protocol (OCSP) ISAPI extension. When OCSP calls ServerSupportFunction to send an HTTP response and the flush operation fails (because the client disconnected early before receiving the response), a reference-decrement in PostedCompletionFunction is never reached. Each such disconnection increments the live reference count by one. An attacker can therefore drive the OCSP service to a permanent DoS by sending a stream of POST requests and disconnecting immediately after each — no large packet or buffer overflow required, just timing.
Victor Yi notes that the same reference-count logic error can produce use-after-free bugs with more severe consequences: if the IIS API context is freed prematurely while another code path still holds a reference, the resulting dangling pointer can lead to RCE.
Remote Code Execution: KDC Proxy Integer Overflow and RDP Gateway UAF
▶ Watch: KDC Proxy RCE — CVE-2024-43639 (26:01)
CVE-2024-43639 targets the KDC Proxy Service (KDCPXY, or KPS), which provides a mechanism for clients to obtain Kerberos tickets through an HTTPS proxy. After a client connects, KPS resolves the Kerberos server address from a client-supplied domain name (via DNS SRV and LDAP queries) and then acts as a TCP client to that Kerberos server — forwarding raw socket data bidirectionally.
Because the socket receive path imposes no length limit on incoming messages, a message length field can be a full 32-bit value. Inside ASN1_int_check, when the message length A2 exceeds word_18 (value: 5), the computation return = word_18 + V9 overflows. An attacker supplying a message length of 0xFFFFFFFB causes this sum to wrap to zero, resulting in a near-zero heap allocation. The subsequent write of message data into that undersized buffer produces a heap overflow. With appropriate heap grooming and memory layout, this constitutes a pre-authentication RCE against any Windows host running the KDC Proxy Service. The crash stack trace shows RCX pointing to a non-writable address at the overflow site.
▶ Watch: RDP Gateway Use-After-Free (30:01)
The Remote Desktop Gateway service contains a race-condition use-after-free. Its WebSocket architecture uses connection IDs to look up live connection structures from a hash table. An attacker can trigger the following sequence: Client 1 connects with connection ID 1, initiating the HttpServerConnection allocation and binding. Before the receive-data thread completes its hash-table lookup, Client 1 disconnects — triggering handleDisconnected, which removes connection ID 1 from the hash table and dereferences HttpServerConnection 1. Client 2 immediately reconnects with the same connection ID 1, creating a new connection structure in the table. The still-running receive-data thread from Client 1 retrieves this new structure but assigns argument 3 (an offset pointer from the old, now-freed HttpServerConnection 1) to the new structure's buffer field. When handleSendResponseCompletion finishes and the last reference to HttpServerConnection 1 drops, that pointer becomes dangling. When Client 2 sends data, WebSocketReceiveRawDataCompletion writes to the dangling address — a write-what-where primitive with attacker-controlled content.
Notable Quotes
"For DoS-type vulnerabilities, crashes caused by memory corruption are not the only concern. For an HTTP service, if the server stops handling client requests, that's also a form of DoS — and high impact."
— Kaishou, 04:00
"I believe that for HTTP services, the handling functions should never stop receiving. After any request, whether valid or invalid, the service must call
HttpReceiveHttpRequestwith request ID set to zero to wait for new client requests."
— Kaishou, 12:00
"If IIS API extensions use ServerSupportFunction carelessly, similar problems can lead to remote code execution."
— Kaishou, 20:01
"Logic-based DoS vulnerability is still in scope for high-value assets — and RCE vulnerabilities are common in HTTP services, especially during parsing of posted data. Try to fuzz it."
— Victor Yi, 34:02
Key Takeaways
- The receiving loop must never terminate. Any code path — valid request, malformed request, or error — must eventually call
HttpReceiveHttpRequestwith request ID zero, or the service will silently stop accepting connections. - Always send a response or cancel the connection. Services that process a request without calling
HttpSendHttpResponseorHttpCancelHttpRequestleak non-paged pool kernel memory; under sustained attack this causes a BSOD. - IIS ISAPI reference counts are an attack surface. Reference count mismatches — especially when clients disconnect before receiving responses — can produce permanent DoS or use-after-free primitives exploitable for RCE.
- Pre-auth RCE is possible without any authentication step. CVE-2024-43639 demonstrates that an unauthenticated remote attacker can achieve RCE against KDC Proxy by supplying a crafted Kerberos message through an attacker-controlled Kerberos server — no credentials or existing session required.
- Use
netsh http show servicestateoffensively. This single command reveals every registered HTTP service on a Windows host, making it a powerful enumeration tool for identifying research targets or attack surfaces in your own environment.
Slides PDF: Not available for this session.
Reviews
Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT
Methodical vulnerability research against Windows built-in HTTP services that produced pre-auth RCE against the KDC Proxy and a write-what-where primitive in RDP Gateway — both unauthenticated, both affecting default Windows configurations. The systematic framework approach that generated multiple CVEs from a single API analysis pass is the real contribution.
Heather Calloway (CISO) — STRONG ACCEPT
CyberKoolun found pre-authentication remote code execution in Windows KDC Proxy — a heap overflow affecting Windows Server 2000 through 2022 — and a use-after-free in RDP Gateway that crashes the service with a single unauthenticated packet. Both are built-in Windows services with broad deployment. The methodology is the finding: systematic review of Windows HTTP services reveals a class of bugs, not isolated incidents.