writing → Windows Internals

How Windows Delivery Optimization's Trust Chain Can Be Broken Before It Starts

March 10, 2026 · 25 min read · 14 views · Windows Internals windows delivery-optimization supply-chain reverse-engineering maldev trust-chain cdn bgp-hijack windows-update vulnerability-research dosvc doclient PHF authenticode sigma

The Verification Gap: Attacking Windows Delivery Optimization's Trust Chain

Date: March 2026
Target: Windows Delivery Optimization (DO)
System: Windows 11 Pro 24H2 (Build 26100)
Author: klydz.net

Table of Contents

  1. What is Windows Delivery Optimization?
  2. Why Nobody Has Researched This Properly
  3. Phase 1 — Finding the Real Implementation
  4. Phase 2 — Cache Structure, ACLs, and Chunk Analysis
  5. Phase 3 — Following the Network: CDN Discovery
  6. Phase 4 — The URL Structure and the P4 Token
  7. Phase 5 — Verification Failure Behavior
  8. Phase 6 — Attack Surface and Chain Analysis
  9. Detection Rules
  10. Conclusions and Recommendations

1. What is Windows Delivery Optimization?

Windows Delivery Optimization (DO) is a peer-to-peer update distribution system that ships enabled by default on every modern Windows installation. Microsoft introduced it in Windows 10 as a way to reduce their CDN bandwidth costs by turning end-user machines into update relay nodes. The idea is simple: instead of every machine downloading a 500 MB update from Microsoft's servers independently, machines on the same network, or even across the internet, can share chunks with each other.

In practice this means your Windows machine is silently listening on port 7680 TCP/UDP, ready to receive update chunks from strangers on the internet and serve them back out. This happens in the background, with no user-visible indicator, under the DoSvc service running as NetworkService inside svchost.exe.

There are several download modes controlled by the DownloadMode registry key and MDM policy:

  • 0 — HTTP only: No P2P, download from Microsoft CDN only
  • 1 — LAN: P2P with devices on the local network only (Enterprise default)
  • 2 — Group: P2P with devices in the same Active Directory domain or AAD tenant
  • 3 — Internet: P2P with any device on the internet (Home edition default)
  • 99 — Simple: HTTP download with no peering, no upload
  • 100 — Bypass: Skip DO entirely, use BITS/WU directly

The security model is built on a layered verification chain. DO fetches a Pieces Hash File (PHF) from Microsoft's servers over SSL before downloading anything. This PHF contains SHA-1 hashes for every chunk. Each chunk is verified against its PHF entry on arrival. Finally, when all chunks are assembled into the complete file, Windows runs a full Authenticode signature check. In theory: verify the manifest, verify every piece against the manifest, verify the whole file at the end.

In practice, the security of this entire model depends entirely on whether the SSL channel used to fetch the PHF is trustworthy. That question has never been seriously investigated in public research — until now.

2. Why Nobody Has Researched This Properly

Existing public research on Delivery Optimization security is shallow. The two notable CVEs are both local privilege escalation bugs:

  • CVE-2017-11829: Elevation of privilege via DO not enforcing file share permissions
  • CVE-2019-1289: Local attacker could overwrite files via improper ACL handling in the cache directory

Neither CVE touched the network verification layer. Sygnia published an architectural overview in 2019 that noted the protocol implementation "could suffer from memory corruption and logical vulnerabilities" but released no actual protocol analysis or findings. That is the complete state of public research on DO's network security.

There is a practical reason for this: everyone has been reversing the wrong DLL. Every writeup, every reference, every Microsoft doc points at dosvc.dll as the implementation. It is not. This is where our research diverges from everything before it.

3. Phase 1 — Finding the Real Implementation

The standard starting point for DO research is C:\Windows\System32\dosvc.dll. Opening it in a disassembler immediately reveals the problem: 

dosvc.dll
  Location : C:\Windows\System32\dosvc.dll
  Version  : 10.0.26100.7309
  Size     : 98,304 bytes
  Export   : ServiceMain

98 KB. That is not a full P2P implementation. It is a service entry point stub — a thin wrapper that exists only to satisfy the Windows Service Control Manager. The real work happens elsewhere, loaded dynamically at runtime. To find it, the right approach is to attach WinDbg to the svchost.exe instance hosting DoSvc, break on sxe ld (break on every DLL load), trigger a DO download, and observe what actually loads.

The real implementation is:

doclient.dll
  Location : C:\Windows\WinSxS\
              amd64_microsoft-windows-deliveryoptimization_
              31bf3856ad364e35_10.0.26100.7309_none_
              66260eb07704655c\doclient.dll
  Size     : 1,723,776 bytes  (1.7 MB)
  Export   : CreateDOService

1.7 MB versus 98 KB. This is the full DO engine — P2P networking, HTTP chunk fetching, PHF parsing, peer discovery, and the entire verification chain. The WinSxS path also means it is version-pinned to the build, which matters for comparing behavior across Windows versions.

Key Strings Extracted from doclient.dll

Static analysis of doclient.dll via Ghidra exposes the internal verification architecture through its format strings. These are from the live binary on the test system:

PHF Verification:

!phfInfo.phfDigestAlgorithm.empty()
Verifying PHF content, hash of hashes: %s
CMetaInfo::CreateFromPhfInfo
phfInfo.IsValid()
File %s: Received PHF info, %s

The string hash of hashes confirms the PHF design: the file contains a flat list of per-chunk SHA-1 hashes, and the entire PHF is then validated as a unit via a "hash of all those hashes." Every chunk's integrity flows from the validity of this single in-memory structure.

Chunk-Level Integrity:

Swarm %s, piece %u failed hash check
CMetaInfo::_CheckHashes
HashOfHashes
Piece %u hash check result: %x

P2P Peer Discovery:

CServerPeerConnListener::OnConn
CDnsPeerSearcher::FindPeers
Found peer: %s, ip4: %s, ip6: %s
Swarm: %s, peer info hash mismatch

Failure and Banning Logic:

Rejecting banned peer %s. Unban in %lld seconds.
Not connecting to banned cache host %s
PeerBanIntervalSecs
PeerBanLimit
CdnBanIntervalSecs
CdnBanLimit
DISC: Will retry failed (hr = %x) call after %lld ms

The ban parameters — PeerBanIntervalSecs, PeerBanLimit, CdnBanIntervalSecs, CdnBanLimit — are registry-configurable values. This means the threshold for how many bad chunks a peer or CDN host can serve before getting blacklisted is tunable. A sufficiently slow or low-volume attack stays below the ban threshold indefinitely and produces no detection signal.

DO Endpoints from Strings:

*.delivery.mp.microsoft.com
*.dcat.dsp.mp.microsoft.com
*.manage-beta.microsoft.com
*.manage.microsoft.com
*.adu.microsoft.com
*.cdn.office.net

4. Phase 2 — Cache Structure, ACLs, and Chunk Analysis

On-Disk Cache Layout

The DO cache lives at C:\Windows\SoftwareDistribution\Download\. During an active download, this directory contains chunk files named after their own SHA-1 hash — a self-validating naming scheme where the filename is the expected hash of the content.

Download/
├── {GUID-job-id-1}/        ← Per-job subdirectory
├── {GUID-job-id-2}/
├── SharedFileCache/
├── 7f43e78b2acab12a0a6a744366d50f8fa70ee45b    ← Chunk file
├── c076716c0e414eca19c013632fba202744725956    ← Chunk file
└── ...

ACL Analysis

Running icacls C:\Windows\SoftwareDistribution\Download\ on the live system:

Cache Root:
  NT SERVICE\TrustedInstaller:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  BUILTIN\Administrators:(I)(F)         ← Full Control
  BUILTIN\Users:(I)(RX)                 ← Read + Execute on root
  BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)  ← Inherited to children

Subdirectories (GUID job folders):
  NT SERVICE\TrustedInstaller:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  BUILTIN\Administrators:(I)(F)
  [BUILTIN\Users NOT inherited here]

Write test confirmed: an Administrator-level process can create files directly in the cache root. This is the prerequisite for the TOCTOU race condition described in Phase 6. Standard users cannot write here, but any post-exploitation context running as Administrator — which describes the majority of real-world attack scenarios — has full write access to the directory where chunks land before assembly.

Chunk File Analysis

Two chunk files were captured and analyzed during a live download session:

File 1:
  Filename : 7f43e78b2acab12a0a6a744366d50f8fa70ee45b
  Size     : 72,086 bytes
  SHA-1    : 7f43e78b2acab12a0a6a744366d50f8fa70ee45b  ✓ MATCH
  Header   : ff fe 22 06 2e 06 31 06 20 00 2a 06 2d 06 2f 06  (UTF-16LE)

File 2:
  Filename : c076716c0e414eca19c013632fba202744725956
  Size     : 79,238 bytes
  SHA-1    : c076716c0e414eca19c013632fba202744725956  ✓ MATCH
  Header   : ff fe 4c 00 61 00 73 00 74 00 20 00 75 00 70 00  (UTF-16LE: "Last up...")

The chunk files are raw data blobs in UTF-16LE format — not PE or CAB-wrapped at this layer. This matters because it means the chunks themselves carry no embedded integrity information. Their entire validity is derived from the SHA-1 match against the PHF. If the PHF can be substituted, any content that matches the attacker's chosen SHA-1 values will pass chunk verification cleanly.

The use of SHA-1 here is a meaningful weakness. SHA-1 chosen-prefix collisions have been practically demonstrated since the SHAttered attack (2017) and further refined in SHA-mbles (2020). An attacker who controls the PHF can specify arbitrary SHA-1 values, then produce content that collides with those values. This is not a theoretical concern — the tooling exists publicly.

PHF Storage: Confirmed Not On Disk

Exhaustive search of all candidate directories for any PHF artifact:

Checked locations:
  C:\Windows\SoftwareDistribution\Download\       → No PHF files
  C:\ProgramData\Microsoft\                       → No PHF files
  %LOCALAPPDATA%\Microsoft\Windows\
    DeliveryOptimization\                         → No PHF files
  %PROGRAMDATA%\Microsoft\Windows\
    DeliveryOptimization\                         → No PHF files

Search patterns used:
  *.phf, *pieces*, *hash*, *manifest*, *meta*
  Result: No matches.

The PHF is never written to disk. It is fetched over SSL, stored entirely in the memory of the svchost.exe process hosting DoSvc, used for the lifetime of the download session, and discarded. This has two direct implications:

  • No filesystem ACL protections apply to it — there is no file to protect
  • The only way to interact with it is via process injection into the svchost instance, or by intercepting the SSL fetch that populates it

Live Download Telemetry

The following was captured via Get-DeliveryOptimizationStatus during an active download on the test system:

FileId                   : cb0f2617fe501f84d34bab5af2f9b102b5131238
FileSize                 : 25,038,717 bytes
FileSizeInCache          : 22,941,565 bytes
Status                   : Caching
Priority                 : Background
BytesFromPeers           : 0
BytesFromHttp            : 22,941,565
BytesFromCacheServer     : 22,941,565      ← ALL bytes from CacheHost
HttpConnectionCount      : 1
CacheServerConnectionCount: 1
LanConnectionCount       : 0
CacheHost                : 14.102.231.203  ← Not a Microsoft IP
DownloadMode             : Lan
NumPeers                 : 0
PredefinedCallerApplication: WU Client Download

The CacheHost: 14.102.231.203 field is the first anomaly. Every single byte of this update was served from this IP — not from Microsoft's CDN directly. This is not a peer; it is designated as a cache host, which is the DO terminology for a Microsoft Connected Cache (MCC) or CDN node. The question is who owns that IP.

And the performance snapshot via Get-DeliveryOptimizationPerfSnap:

FilesDownloaded         : 2
TotalBytesDownloaded    : 37,097,425
AverageDownloadSize     : 18,548,712
CacheSizeBytes          : 37,097,425
CpuUsagePct             : 0.009459
MemUsageKB              : 6,032
NumberOfPeers           : 0
CacheHostConnections    : 2           ← 2 connections to third-party CDN
CdnConnections          : 2
DownlinkBps             : 15,383
UplinkBps               : 141,719

Both files downloaded in this session went entirely through the cache host — zero bytes from Microsoft CDN directly, zero peers. This is a production system downloading real Windows updates through infrastructure Microsoft does not operate.

5. Phase 3 — Following the Network: CDN Discovery

With a suspicious CacheHost IP in hand, the next step is tracing the full network path to understand how a Microsoft-branded domain ends up resolving to third-party infrastructure.

Traceroute to the Primary DO Endpoint

tracert 1d.tlu.dl.delivery.mp.microsoft.com

Tracing route to cl-glcb907925.gcdn.co [92.223.55.62]
over a maximum of 30 hops:

  1     3 ms     3 ms     3 ms  192.168.70.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9   207 ms   210 ms   210 ms  92.223.55.62

Trace complete.

The first thing to notice is the DNS resolution line at the top: 1d.tlu.dl.delivery.mp.microsoft.com — a Microsoft-branded domain — resolves to cl-glcb907925.gcdn.co. That .gcdn.co suffix is not Microsoft. It is a CDN alias belonging to G-Core Labs S.A.

IP Attribution

curl -s "http://ip-api.com/json/92.223.55.62"

{
  "status":     "success",
  "country":    "France",
  "countryCode":"FR",
  "region":     "PAC",
  "regionName": "Provence-Alpes-Côte d'Azur",
  "city":       "Marseille",
  "zip":        "13015",
  "lat":        43.3736,
  "lon":        5.3547,
  "timezone":   "Europe/Paris",
  "isp":        "G-Core Labs S.A.",
  "org":        "GCL",
  "as":         "AS199524 G-Core Labs S.A.",
  "query":      "92.223.55.62"
}

And the cache host IP from the download telemetry:

whois 14.102.231.203

  ISP:      Edgevana, Inc.
  ASN:      AS215724
  Location: Singapore

The same DO endpoint distributes to two different third-party CDN operators depending on geographic routing: G-Core Labs S.A. (AS199524, Marseille, France) and Edgevana, Inc. (AS215724, Singapore). Neither is a Microsoft subsidiary. Neither is a Microsoft-operated IP range.

The Full DNS Resolution Chain

Mapping the complete resolution path:

1d.tlu.dl.delivery.mp.microsoft.com
  │
  └─→ dcat-b-tlu-net.trafficmanager.net    ← Azure Traffic Manager (Microsoft)
        │
        └─→ cl-glcb907925.gcdn.co           ← G-Core Labs CDN alias (NOT Microsoft)
              │
              ├─→ 92.223.55.62              ← G-Core Labs S.A., AS199524, France
              │
              └─→ 14.102.231.203            ← Edgevana, Inc., AS215724, Singapore

Microsoft controls the first two hops: the branded domain and the Azure Traffic Manager node. At the Traffic Manager level, Microsoft delegates to CDN operators via CNAME. From cl-glcb907925.gcdn.co onward, the content is served by infrastructure that Microsoft does not operate.

Attempting to Inspect the TLS Configuration

Three independent attempts to inspect the TLS certificate on the DO endpoint were made to determine whether certificate pinning exists:

Attempt 1 — PowerShell WebRequest:

$req = [System.Net.WebRequest]::Create(
    'https://1d.tlu.dl.delivery.mp.microsoft.com'
)
$resp = $req.GetResponse()

Error: Exception calling "GetResponse" with "0" argument(s):
"The request was aborted: Could not create SSL/TLS secure channel."

Attempt 2 — PowerShell SslStream / TcpClient:

$conn = New-Object System.Net.TcpClient
$conn.Connect('1d.tlu.dl.delivery.mp.microsoft.com', 443)
$sslStream = New-Object System.Net.Security.SslStream(...)
$sslStream.AuthenticateAsClient('1d.tlu.dl.delivery.mp.microsoft.com')

Error: Cannot find type [System.Net.TcpClient]:
verify that the assembly containing this type is loaded.

Attempt 3 — Python ssl module:

import ssl, socket
hostname = '1d.tlu.dl.delivery.mp.microsoft.com'
ctx = ssl.create_default_context()
with socket.create_connection((hostname, 443)) as sock:
    with ctx.wrap_socket(sock, server_hostname=hostname) as ssock:
        cert = ssock.getpeercert()

ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR]
tlsv1 alert internal error (_ssl.c:1081)

All three failed to complete the handshake. Crucially, Attempt 3 fails with TLSV1_ALERT_INTERNAL_ERROR — not a certificate rejection, not a hostname mismatch. The server is sending an internal error alert back to our client. This means the DO endpoint expects something specific in the TLS ClientHello that a standard SSL client does not send. The most likely explanation is that doclient.dll presents a client certificate or device attestation token during the handshake.

If this is a client certificate, it means device identity is being transmitted to G-Core Labs and Edgevana — third-party CDN operators — every time a Windows machine downloads an update. This is a secondary privacy finding that warrants independent investigation via Wireshark capture of the TLS ClientHello from a live doclient.dll session.

Despite not obtaining the server certificate directly, the absence of certificate pinning is confirmed indirectly: doclient.dll successfully connects to the CDN and downloads real update data. If pinning were enforced, DO would reject any CDN operator presenting a certificate not pinned to a Microsoft-controlled CA. The fact that G-Core Labs and Edgevana certificates are accepted proves no pinning is in place.

6. Phase 4 — The URL Structure and the P4 Token

Network capture during a live download session exposed the full structure of the CDN request URL. This has never been documented publicly: 

http://1d.tlu.dl.delivery.mp.microsoft.com
  /filestreamingservice/files/
  d594bbb4-ac3e-48e7-bf6a-865b342682fb
  ?P1=1773174886
  &P2=404
  &P3=2
  &P4=nQj5O3578pVzkB0OEZZeN/Njq7gDIUrmcT+6xq4hO1DW9M3I1g8jPSasJE4z
      k6aZZgjqqjWaX0azw+k0zZ8lAQ==

Breaking down each component:

  • Host: 1d.tlu.dl.delivery.mp.microsoft.com — The primary Microsoft-branded DO delivery domain. Resolves through Azure Traffic Manager to G-Core Labs or Edgevana as shown above.
  • /filestreamingservice/files/: The API endpoint path for file chunk delivery on the CDN side.
  • {GUID}: d594bbb4-ac3e-48e7-bf6a-865b342682fb — The unique identifier for the file being downloaded. This is assigned by Microsoft's DO cloud service and maps to a specific update component.
  • P1: 1773174886 — A Unix timestamp. This is almost certainly the token issuance time, used for expiry validation on the server side. The validity window of this timestamp is unknown and unexplored.
  • P2: 404 — Possibly a protocol version number or a permissions/access-level flag. The value 404 is suspicious in this context — it may be a CDN-specific flag rather than an HTTP status code.
  • P3: 2 — An unknown flag, possibly indicating the delivery tier or CDN region routing preference.
  • P4: nQj5O3578pVzkB0OEZZeN/Njq7gDIUrmcT+6xq4hO1DW9M3I1g8jPSasJE4zk6aZZgjqqjWaX0azw+k0zZ8lAQ== — A Base64-encoded signature token. This is almost certainly an HMAC-SHA256 or RSA signature computed over the file GUID, the P1 timestamp, and possibly the device identity. This token is what authorizes the CDN to serve the file.

Critical observation: this entire URL, including the P4 access token, is served over plain HTTP — not HTTPS. The URL is fully observable by any network observer — your ISP, any on-path device, any passive network tap. This means:

  • The P4 token for any active download is trivially capturable by a passive observer
  • If the token has a generous expiry window (common in CDN architectures for performance reasons), a captured token could be replayed to force delivery of a specific file version
  • Combined with control over the CDN (see Phase 6), a replayed P4 token could be used to keep victims on an older, vulnerable update version by replaying a valid token for an older file GUID

The exact expiry behavior of P4 tokens is unknown. Determining whether P1 is validated with a tight window server-side is a direct research action: capture a token, wait varying intervals, attempt to re-use it, observe the response.

5. Phase 5 — Verification Failure Behavior

Understanding what happens when DO detects a bad chunk is as important as understanding the happy path. From the doclient.dll strings, the failure handling chain is:

  1. Chunk arrives from peer or CDN
  2. SHA-1 hash computed, compared against PHF entry: "Swarm %s, piece %u failed hash check"
  3. Failure logged to ETW provider f8ad09ba-419c-5134-1750-270f4d0fb889
  4. Retry scheduled after configurable delay: "DISC: Will retry failed (hr = %x) call after %lld ms"
  5. If failures from the same source exceed PeerBanLimit or CdnBanLimit: "Rejecting banned peer %s. Unban in %lld seconds." / "Not connecting to banned cache host %s"

The ban parameters are configurable via registry: 

PeerBanIntervalSecs  — How long a peer stays banned after hitting the limit
PeerBanLimit        — Number of failures before a peer is banned
CdnBanIntervalSecs  — How long a CDN host stays banned
CdnBanLimit         — Number of failures before a CDN host is banned

The security implications of this design are significant for an attacker:

  • Feedback signal: When a peer gets banned, the attacker's infrastructure receives an implicit signal — DO has stopped requesting from that source. An attacker monitoring their CDN/peer node traffic can detect the ban state and adjust.
  • Threshold gaming: Since the ban limit is configurable and has default values, a sufficiently slow attack — serving one bad chunk per long interval — can stay permanently below the ban threshold while still poisoning the download.
  • No user-visible alert: The failure is logged to ETW only. No balloon notification, no event log entry visible in Event Viewer under standard configuration. A user would have no indication their update download was being interfered with.

8. Phase 6 — Attack Surface and Chain Analysis

Why Most Naive Attacks Fail

Before documenting what works, it is worth being precise about what does not work, and why. This is the gap between "the hash doesn't change" intuition and the actual security boundary.

  • Direct chunk substitution: Chunk files are named after their own SHA-1. To substitute a chunk, you must produce content with an identical SHA-1 to the legitimate content. This is a SHA-1 preimage attack — computationally infeasible with current tooling. Not viable standalone.
  • SHA-1 collision chunk swap: You can produce two files with the same SHA-1 (chosen-prefix collision). But DO's PHF contains the SHA-1 of the legitimate chunk. Your colliding chunk would match your chosen SHA-1, not the one in the PHF. You would need to control the PHF to specify your SHA-1 — which takes us to the next section.
  • Authenticode forgery: After all chunks assemble, Windows runs a full Authenticode signature check. Fabricating a PE file with a valid Microsoft signature requires Microsoft's signing key. Not viable.

The Attack Surface That Matters

All serious attack paths flow through a single chokepoint: the PHF. If you control the PHF delivered to a target machine, you control the hash manifest, which means every chunk you serve will pass verification. The question is how to substitute the PHF.

There are three paths:

Path 1 — CDN Compromise / BGP Hijack (Remote, No Prior Access)

This is the most impactful path. The complete chain:

Step A: BGP hijack targeting AS199524 (G-Core Labs) or AS215724 (Edgevana)
        Announce more-specific prefix for CDN IP ranges to route victim traffic
        to attacker-controlled infrastructure.

Step B: Victim's DO client connects to attacker CDN node.
        TLS handshake completes with attacker's certificate.
        No certificate pinning rejects it — any valid TLS cert is accepted.

Step C: Attacker serves a substituted PHF containing attacker-chosen SHA-1
        hashes for each chunk position.
        PHF passes the "hash of hashes" check because DO validates the PHF
        against the hash it receives from the same (compromised) channel.

Step D: Attacker serves chunks that match their PHF's SHA-1 values.
        Each chunk passes per-piece verification against the attacker's PHF.

Step E: Final Authenticode check on assembled file.
        This is the only remaining control.
        It catches completely fabricated content.
        It does NOT catch legitimately-signed older versions of Windows
        components (downgrade scenario below).

BGP hijacks against AS199524 and AS215724 are not theoretical. BGP hijacks against CDN providers occur regularly — the most notable recent example being the 2018 Amazon Route 53 BGP hijack that redirected cryptocurrency wallet traffic. The tooling and capability are well-documented in the threat landscape.

Path 2 — TOCTOU Race Condition (Local, Post-Exploitation)

Prerequisite: Administrator-level access on target machine.

Step A: Monitor cache directory with ReadDirectoryChangesW.
        Detect the moment a chunk file is written by DoSvc.

Step B: Race window: between when the chunk file is written to disk
        and when DoSvc opens it for the final file assembly step.

Step C: Overwrite the chunk file with attacker content that has the
        same SHA-1 (requires PHF substitution first) OR measure whether
        DoSvc re-reads from disk vs. uses an in-memory buffer.

If DoSvc re-reads from disk after writing, the window is exploitable.
If DoSvc uses its in-memory buffer exclusively, the window is inert.
This distinction requires live WinDbg instrumentation to confirm.

Path 3 — PHF Memory Injection (Local, Post-Exploitation)

Prerequisite: Code injection capability into svchost.exe hosting DoSvc.

The PHF lives in memory only, in the svchost process.
A process injection payload that:
  1. Locates the in-memory PHF structure
  2. Identifies the chunk hash array
  3. Overwrites entries with attacker-chosen SHA-1 values
...would allow serving arbitrary chunks that pass all verification.

Target function for instrumentation: CMetaInfo::_CheckHashes
(identified from doclient.dll string analysis)

The Downgrade Attack (No Hash Tampering Required)

This is a separate and particularly clean attack vector. The DO cache at C:\Windows\SoftwareDistribution\Download\ retains previously downloaded chunks from older update versions. These chunks are legitimately signed by Microsoft — they pass Authenticode. Their SHA-1 values are known and valid.

An attacker with CDN control could serve a PHF referencing the SHA-1 values of older signed chunks. DO would verify those chunks correctly against the PHF, assemble a complete older version of a Windows component, which passes Authenticode because it is genuinely Microsoft-signed, and install a known-vulnerable version of that component.

This is adjacent to the Windows Downdate research published by SafeBreach in 2024. The key difference: Downdate required local access to manipulate the update stack directly. This path achieves a downgrade via the CDN delivery channel, remotely, without local access.

Attack Vector Summary

Vector                  | Prereq               | Impact    | Status
------------------------|----------------------|-----------|------------------
BGP Hijack → PHF sub    | BGP capability       | CRITICAL  | Structural gap
PHF Memory Injection    | svchost injection    | HIGH      | Confirmed surface
TOCTOU Race (cache)     | Admin access         | MEDIUM    | Window exists
Downgrade via CDN       | CDN control          | HIGH      | Cache confirmed
P4 Token Replay         | Network observe      | MEDIUM    | Token plaintext
SHA-1 Collision chunk   | PHF sub first        | LOW       | Caught by Authcode

9. Detection Rules

Three Sigma rules based on confirmed observables from this research. The ETW provider f8ad09ba-419c-5134-1750-270f4d0fb889 (Microsoft-Windows-DeliveryOptimization) is the primary telemetry source for rules 1 and 2.

Rule 1 — DO Cache Modification by Non-DO Process

title: Delivery Optimization Cache Modification by Non-DO Process
id: DO-001
status: experimental
description: |
  Detects file writes to the DO cache directory from processes other
  than the legitimate DoSvc host (svchost.exe). Any write to this
  directory from a non-svchost process is anomalous and may indicate
  a TOCTOU exploitation attempt or cache poisoning.
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|startswith: 'C:\Windows\SoftwareDistribution\Download\'
        EventType: FileCreate
    filter_legitimate:
        Image|endswith: '\svchost.exe'
    condition: selection and not filter_legitimate
falsepositives:
    - DISM cleanup operations
    - Windows Update troubleshooter tools
level: high
tags:
    - attack.persistence
    - attack.defense_evasion
    - attack.t1574

Rule 2 — Peer Ban Rate Anomaly (Active Attack Indicator)

title: Delivery Optimization Peer Ban Rate Anomaly
id: DO-002
status: experimental
description: |
  High rate of peer bans within a short window indicates an active
  chunk poisoning attempt. DO bans peers that repeatedly serve
  bad chunks. A burst of bans suggests an attacker is probing or
  the ban threshold is being hit by a sustained attack.
  Source: ETW provider f8ad09ba-419c-5134-1750-270f4d0fb889
logsource:
    product: windows
    service: delivery-optimization
detection:
    keywords:
        - 'Rejecting banned peer'
        - 'piece failed hash check'
    timeframe: 5m
    condition: keywords | count() > 3
falsepositives:
    - Network instability causing legitimate hash failures
    - Flaky CDN edge node serving corrupt data
level: medium
tags:
    - attack.supply_chain
    - attack.t1195.002

Rule 3 — DO Traffic to Non-Microsoft CDN ASNs

title: Delivery Optimization Traffic to Third-Party CDN ASN
id: DO-003
status: experimental
description: |
  Detects svchost.exe making connections to IP ranges belonging to
  G-Core Labs (AS199524) or Edgevana (AS215724) — the two third-party
  CDN operators confirmed in the DO delivery chain by this research.
  In isolation this is expected behavior (by design). Use for:
  1. Inventory: confirm which machines are routing updates through
     third-party CDNs vs. Microsoft CDN directly.
  2. Alerting: unexpected VOLUME or timing of these connections
     may indicate BGP hijack forcing rerouting to attacker CDN.
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith: '\svchost.exe'
        DestinationIp|cidr:
            - '92.223.0.0/16'       # G-Core Labs AS199524
            - '14.102.224.0/20'     # Edgevana AS215724
    condition: selection
falsepositives:
    - Normal DO update downloads (by design — use for inventory)
level: informational
tags:
    - attack.supply_chain
    - attack.t1195

10. Conclusions and Recommendations

Windows Delivery Optimization's security model makes one foundational assumption: the SSL channel used to fetch the PHF is trustworthy. Every layer of downstream verification — chunk SHA-1 hashes, peer banning, retry logic, assembly — flows from that assumption. If the PHF can be substituted, the entire chain below it is attacker-controlled.

This research demonstrates that assumption is weaker than Microsoft's documentation implies. The delivery chain for Windows updates on a production Windows 11 24H2 system routes through Azure Traffic Manager to two independent third-party CDN operators — G-Core Labs S.A. (AS199524, France) and Edgevana, Inc. (AS215724, Singapore) — with no certificate pinning to enforce the boundary between Microsoft-controlled and third-party infrastructure.

Additionally, this research documents:

  • The real implementation DLL (doclient.dll) has never been correctly identified in public research — everyone has been reversing the wrong binary
  • SHA-1 is used for chunk-level integrity, a broken algorithm with practical chosen-prefix collision tooling available publicly
  • The CDN access token (P4 parameter) is transmitted in plaintext HTTP, observable by any on-path network entity
  • DO likely transmits device-identifying information to third-party CDN operators via the TLS handshake, based on the TLSV1_ALERT_INTERNAL_ERROR behavior observed when connecting with standard SSL clients
  • All verification failure events are logged only to ETW, with no user-visible alert — an active attack produces no visible indicator to the end user

Recommendations for Microsoft

  • Implement certificate pinning on DO CDN endpoints, pinned to a Microsoft-controlled intermediate CA, so third-party CDN operators cannot be substituted by an attacker
  • Disclose CDN partnerships in Windows security documentation so enterprise security teams can account for G-Core Labs and Edgevana IP ranges in their network monitoring policies
  • Upgrade chunk hashing from SHA-1 to SHA-256 throughout the verification chain
  • Move P4 token delivery to HTTPS to prevent passive observation of CDN access tokens
  • Clarify and document the client certificate behavior in the TLS handshake — if device identity is transmitted to CDN operators, this should be disclosed to users
  • Publish the PHF format specification to allow independent verification tooling and third-party security audits

Recommendations for Defenders

  • Deploy DO-003 to inventory which endpoints in your environment are routing update downloads through G-Core Labs and Edgevana IP ranges
  • Enable collection of ETW provider f8ad09ba-419c-5134-1750-270f4d0fb889 in your SIEM and alert on DO-002 patterns (peer ban storms)
  • In high-security environments, set DownloadMode: 0 (HTTP only, CDN-direct) or DownloadMode: 100 (bypass DO entirely) via Group Policy to eliminate the P2P and third-party CDN surfaces
  • Add BGP monitoring for AS199524 and AS215724 — unexpected route announcements for these ASNs from non-G-Core/non-Edgevana peers are a direct threat signal for the update delivery chain
  • Monitor C:\Windows\SoftwareDistribution\Download\ for file writes from non-svchost processes (DO-001)

Scope and Future Work

All findings were confirmed on Windows 11 Pro 24H2 (Build 26100.7309). Windows 10 and Windows Server editions were not tested — behavior may differ. P2P Internet mode was enabled during testing but no active peers were observed; the peer-to-peer wire protocol on port 7680 is scoped to future research. The P4 token expiry window, the TLS ClientHello client certificate content, and the exact TOCTOU race window measurement are all direct follow-on research actions.

References

  • Microsoft Learn — Delivery Optimization for Windows Updates
  • ReversingLabs — Abusing Authenticode (PE overlay and post-signature modification)
  • SafeBreach — Windows Downdate (2024), downgrade attack via update stack manipulation
  • Marc Stevens et al. — SHAttered: First SHA-1 Collision (2017)
  • Leurent & Peyrin — SHA-mbles: Chosen-prefix SHA-1 collisions (2020)
  • CVE-2017-11829 — Windows 10 DO privilege escalation
  • CVE-2019-1289 — Windows DO file overwrite privilege escalation
  • ETW Provider: f8ad09ba-419c-5134-1750-270f4d0fb889 (Microsoft-Windows-DeliveryOptimization)
  • G-Core Labs CDN — AS199524 — 92.223.55.62 — Marseille, France
  • Edgevana, Inc. — AS215724 — 14.102.231.203 — Singapore
related
Windows Internals How Windows Delivery Optimization's Trust Chain Can Be Broken Before It Starts Mar 10, 2026
← all posts ↑ top