0x000/ms-private
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

first commit

Browse Source
This commit is contained in:
unknown committed 2026-09-19 20:55:32 -04:00
1 parent 831814283e
commit 7aacc0b63f
29 files changed
+5114
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/OFFLINE-UPDATES.md
+55
View File
@@ -0,0 +1,55 @@
# Updates without direct Microsoft contact from the protected PC
Reviewed 19 September 2026. The implemented component is a local inventory and bundle-integrity verifier. The isolation boundary, offline scan and package installation workflow below still require lab validation. No update package was downloaded or installed on the development host.
## Choose the actual boundary
| Mode | Protected PC sends to Microsoft? | Maintenance | What changes |
| --- | --- | --- | --- |
| Reduced collection with online security | Yes, for retained services | Normal Windows, AV and app updates | Supported privacy settings and measured optional-feature restrictions |
| Selective egress with update exceptions | Yes, on allowed update/security paths | Online updates if all dependencies work | Narrow feature/app rules; explicit residual traffic and compatibility tests |
| Isolated Windows with a separate collector | No direct Internet traffic while isolation holds | Signed packages transferred from another machine | Local antivirus remains useful; online reputation and cloud protection are unavailable |
Downloading directly over HTTPS requires outbound requests and protocol traffic. An inbound allow rule cannot supply an update that the client never requested. A firewall's direction describes who initiates a connection, not whether its payload is an upload or download. A proxy or VPN changes the intermediary; it does not inherently remove identifiers from application requests.
For the strongest option, keep the protected Windows environment disconnected from the Internet, ideally at a separate enforcement boundary: no attached network adapter in a Windows VM, or physically disconnected networking on a separate PC. A gateway with no WAN forwarding can support an isolated local network, but its configuration must be tested. Do not call a hostname denylist an air gap. If browsing is needed, use a separate connected environment; copying files back introduces its own inspection requirements.
The collector is a separate trust domain. It contacts Microsoft and other publishers and exposes its own network metadata. It fetches generic published files rather than forwarding the protected PC's live update requests, credentials, cookies or tokens. This is not a promise that Microsoft receives no requests anywhere.
## Package workflow
1. **Inventory locally.** `./Offline-Updates.ps1 -Json` reports only OS build, revision, edition and architecture. It makes no network requests. Select the correct product and architecture; Windows 10 needs independently verified support/ESU eligibility. Matching a build number is not proof of eligibility.
2. **Select packages on the collector.** Review the official KB and Microsoft Update Catalog entry, prerequisites, architecture, known issues and reboot instructions. Windows 11 24H2 and later can require earlier checkpoint cumulative updates. Keep a recorded order rather than guessing from filenames. [Checkpoint update documentation](https://learn.microsoft.com/en-us/windows/deployment/update/catalog-checkpoint-cumulative-updates).
3. **Authenticate on the collector.** Use publisher downloads and supported signature/catalog validation for that package format, with current certificate/revocation information. An arbitrary hash supplied next to a file is not proof of authenticity. Record the exact source, version/KB, collection date and SHA-256 after authenticating the file. Do not assume `Get-AuthenticodeSignature` handles every MSU/CAB package like a signed EXE. The Windows servicing stack must still perform its normal package validation.
4. **Prepare the transfer manifest.** Copy `config/offline-bundle.example.json` into a directory with the selected packages and replace every placeholder. Record declared prerequisites as earlier package IDs. The example deliberately fails verification until populated; it is not a list of current updates.
5. **Transfer a minimal bundle.** Copy packages and manifest through controlled removable media. A one-way workflow reduces opportunities to carry identifying reports back out. Reject unknown executables and inspect transferred content. USB storage alone is not a hardware data diode.
6. **Verify on the isolated PC.** Run `./Offline-Updates.ps1 -Mode Verify -Manifest 'D:\Updates\bundle.json' -Json`. The verifier rejects remote paths, reparse-point paths, path traversal, missing files, hash mismatches, target mismatch, duplicates and invalid declared prerequisite order. It never downloads, installs, changes services or evaluates manifest commands. Its local file access may still be observed by existing security software; process behavior does not isolate the entire OS.
7. **Install through the supported package mechanism.** Follow the selected KB's instructions and retain Windows signature checking. Recheck files immediately before execution and keep the bundle protected from modification. The current helper intentionally does not execute packages. A verified hash result is not an installation instruction or a complete patch report.
8. **Reboot, rescan and check security.** Confirm resulting build/KB and protection versions, check failures and pending reboot, and repeat functional tests. Keep servicing logs locally with bounded retention. Do not delete `WinSxS`, `SoftwareDistribution` or installer caches as a privacy cleanup shortcut.
Microsoft supports a Windows Update Agent scan using the signed `Wsusscn2.cab` without querying Windows Update. The CAB contains security-update metadata, not update binaries or complete third-party coverage. The proposed scanner will use a temporary scan service, explicit offline search, cleanup and an externally enforced isolation boundary. It is not implemented in this release. [WUA offline scan](https://learn.microsoft.com/en-us/windows/win32/wua_sdk/using-wua-to-scan-for-updates-offline), [Online property](https://learn.microsoft.com/en-us/windows/win32/api/wuapi/nf-wuapi-iupdatesearcher-put_online).
## Security maintenance beyond Windows cumulative updates
| Component | Offline maintenance requirement | Residual cost / verification |
| --- | --- | --- |
| Windows and .NET | Correct cumulative/security packages and prerequisites | Check KB/build, reboot and applicability; update tooling must remain intact |
| Defender | Current security intelligence, engine and platform packages through supported distribution | Cloud analysis and online first-seen reputation do not become offline features. Check all three versions, not only signature date. [Defender update channels](https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-antivirus-updates) |
| Certificate trust | Planned trusted/disallowed certificate-list maintenance | Offline trust information can become stale; do not disable certificate validation to make installations pass. [Trust-list maintenance](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates) |
| Tor, Zen, Helium and other apps | Official signed installers/updates and dependencies | Browser vulnerability fixes have their own cadence. Store-only dependencies may complicate fully offline maintenance |
| Firmware, drivers, Secure Boot and recovery environment | Vendor-supported offline methods and separate tracking | A current OS build alone does not establish coverage of these components |
| Offline scanner metadata | Fresh signed scan catalog and recorded retrieval date | A zero-result scan is limited to that catalog and scan scope |
Decide an operational maintenance cadence and an emergency-update process before deployment. A scheduled package download on a collector is possible later; no recurring automation has been created. A stale offline machine can be less secure than an online machine with minimized diagnostics.
## Egress implementation rules
- Keep the current host online while developing. Validate containment on a disposable VM first, using an external gateway view and local process attribution. Do not test by dropping this host's connections.
- Avoid indiscriminate Microsoft/Azure address blocking: shared services and changing endpoints create overblocking and gaps. A third-party website can use Microsoft-hosted infrastructure without being an OS telemetry destination.
- For a Windows outbound-default-block profile, inventory existing allow rules first. Do not combine an explicit blanket block with supposed exceptions: explicit blocks take precedence. Cover every profile, interface, IPv4/IPv6 and TCP/UDP path. [Firewall precedence](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules).
- Do not assume a download-only proxy filters identifiers. A later update-cache design must serve pre-fetched content and have no transparent upstream fallback. Its own requests and logs need a separate policy.
- Measure boot, sign-in, idle, update checks, browsers, reconnect and sleep/wake. Record rejected and successful flows, and test recovery locally. Do not use domain ownership alone as evidence of purpose.
## Delivered verification
`Offline-Updates.ps1` and `src/Wind.OfflineUpdates.psm1` implement local inventory and integrity verification. Nineteen tests passed in PowerShell 7 and Windows PowerShell 5.1 using synthetic package bytes. The real host inventory was read successfully. No real update applicability, publisher authenticity, installation, offline WUA scan or containment test has passed yet; those remain explicit tasks.