I usually try my best to post a completed work here, so please treat this post as an exception just to prove a general rule 🙂 I only stumbled upon it today and seeing opportunities it may offer I got too excited to wait and have to post it even if I know lots of work still needs to be done.
Today I noticed that Windows Update (and also SIHClient.exe) are referencing a Registry key:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Test
I love testing-related registry entries as they usually lead to interesting discoveries. For instance, many Windows services refer to TestHooks entries that enable various debugging features e.g. you can set HKLM\SECURITY\test\TestHooks\Volatile\TreatDeviceAsXbox to 1 to make your OS look like XBOX.
Anyway…
So once I found out about that Test key I started digging. I quickly discovered that the service is trying to read a value of:
- HKLM\…\WindowsUpdate\Test\AlternateTestCabPath
I added this value and pointed it to c:\test, and soon after I was able to confirm that Windows Update is now trying to read C:\test\autest.cab.
With these two keywords I went to look at the code and discovered that:
- C:\test\autest.cab must include a file autest.txt
- autest.txt must include text:
Windows Update Test Key Authorization File
yyyy-mm-ddThh:mm:ss
- and the autest.cab must be signed
You can create a test CAB file using makecab:
makecab autest.txt autest.cab
My tests stopped here at the moment. Almost. I noticed that the signature check can be possibly bypassed via ShouldIgnoreTrustVerificationError routine (name is from symbols).
Coming back to the main point of this post: once these conditions are met, a number of test features will be enabled.
Since I describe it in the Beyond the good ol’ Run key series, let’s start with the persistence tricks. There are 3 of them, at least.
If any of these entries are present under:
- HKLM…\WindowsUpdate\Test\EventerHookDll = <path>
- HKLM…\WindowsUpdate\Test\AllowTestEngine = <path>
- HKLM…\WindowsUpdate\Test\AlternateServiceStackDLLPath = <path>
… these DLLs will be loaded by Windows Update (that will be running in a test mode).
There are many other very interesting options under this Test key node and these I could quickly name are as follows:
- AllowAdmin
- AllowNonPPL
- IsStateSeparationEnabled
- AllowTestEngine
- SLSNoCache
- SLSExpireContent
- SLSFixedURL
- SLSWriteRequestToRegistry
- SLS
- SLSCDNXML
- SLSResponseCabOverridePath
- SLSExpireSecsInADay
- ImpersonateDefApps
- SubCAOverrides
- SkipQuorumSignatureChecks
- ForceGetNewAgentToken
- TargetServiceForAuthTicket
- ForceAddTicketsToFail
- TestACLineStatus
- TestBatteryFlag
- TestBatteryLifePercent
- ForceHandlersInproc
- AllowAllReadinessLevelsForFlighting
- SecsInADay
- UseWUServer
- UseDeploymentProvider
- ECPFailOptimizedUpdateDownloadAtIndex
- Security\HashSubstitution
- CallbackEventExpirationAge
- IsInOOBE
- PRECacheDir
- TreatInstallAsUninstallInOfflineCab
- AllowShutdownWhileDebugging
- AppxHandler\DataSourceScheme
- AppxHandler\DataSourceClsid
- RecordTSCallResult
- Policies\WindowsUpdate
- Policies\WindowsUpdate\AU
- IsAoAcDevice
- EnableCSSimulator
- Download
- BatchFlushAgeSus
- SamplingValueThresholdOverride
- DetectSamplingValueThresholdOverride
- AppCategoryCacheLifetime
- RequestCompression
- TestClientToken
- UseBasicAuthProvider
- DeviceAttributes
- DisableCatScan
- AlwaysFireScanEvent
- DisableDOUsage
- DisableRegulation
- SLSBlockAsyncRefreshOnExpire
- SlsExpireCache
- SLSNoCache
- AllowSystemDriveAsExternalVolume
- ElevateNonAdmins
- DisableWindowsUpdateAccess
- NoAppXCaching
- BlockedClientIds
- AssumeCostedNw
- RevisionsChangeContent
- NoAppStreaming
- AreMSPreferredUpdatesExemptedOverride
- UpdateState
- MOOverrides
- AppxHandler\CacheLifetimeSecondsOverride
- ForcedIdleShutdown
- Download\MSPreferredClassificationIdsOverride
- MaxAppDownloadJobSize
- AlternateUpdateApprovalList
- MOLimitsInKB
- SkipLoadingReserveManager
- TreatNewUpdatesAsChangedOrOutOfScopeUpdatesInOfflineCab
- ForceUserProxyForReporting
- WSUSInventoryTestServer
- InventoryCabPath
- ProcessHandlerResult
- DeviceAttributes
- CbsHandler\MaxRequests
- CbsHandler\DpxResumeFirstResult
- CbsHandler\DpxResumeNextResults
- SystemSpecNode\HWID
- HardwareIdOverride
- DriverRecoveryIDs
- DriverQuery-ProblemCode
- DriverQuery-ProblemStatus
- DriverQuery-Reboot
- WinSetupHandlerCacheLifetimeSecondsOverride
- WinSetupHandlerSkipCrossSessionRegistration
- HandlerSecsInADay
- BreakOnHandlerInstallCall
- TestCert
- AllowAllReadinessLevelsForFlighting
- UseDeploymentProvider
I will lie if I say that I know what all of it means, but some of these name imply that with the test settings you could potentially use alternative Cert Store, DNS settings, allow any SSL connection, downgrade hashes to SHA1, override a number of policies, elevate non-admins, and even download files from different urls (e.g. whatever is under InventoryCabPath is downloaded to the system, if exists) etc.
All in all, this is a tip of the iceberg, and once properly researched it may enable avenues for more clandestine C2, persistence and perhaps even lateral movement tricks (adding keys to the remote registry will make Windows Update download/load code for you).
