UACME vs the announced Administrator protection in the Windows Canary builds
Closed this issue · 7 comments
Hello again. Maybe somebody would be interested in this topic.
Microsoft recently introduced a new security feature against UAC abusing tricks, "Administrator protection". They claim that it is off by default, but can be enabled via gpedit.
Wanted to test UACME against this new feature. But what I'm curious about is that the UAC protection toggles in this OS version (mine is 27723) are absolutely identical to ones from 24H2. (\Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options)
Maybe somebody has insights about this.
Sorry for spamming, feel free to close this if it isn't related to the tool.
It will work, as it will throw credentials window for each autoelevation request when configured. This will return you in Windows Vista times, but 18 years later apps evolved enough to not spam users with neverending UAC requests. However administrative tasks will be a pain in the ass if they are not executed from already elevated process.
The settings name btw is "TypeOfAdminApprovalMode" and its a DWORD in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg Values\MACHINE/Software/Microsoft/Windows/CurrentVersion/Policies/System/
Interesting. But, as we can see from the pic above "Configure type of Admin Approval Mode" exists in 24H2 too. Perhaps they implemented something new behind this toggle then.
And does it work on 24H2?
Will check it out.
Results are almost the same, but not quite. Tested on the latest Canary 27729 and 24H2 (26100) with default settings for UAC as shown on the pic above.
UacMethodSXSConsent, //+ doesn't work on both
UacMethodDISM, //+ works on both
UacMethodWow64Logger, //+ works on both
UacMethodUiAccess, //+ works on both
UacMethodMsSettings, //+ works on both
UacMethodDiskSilentCleanup, //+ doesn't work on both
UacMethodJunction, //+ works on both
UacMethodSXSDccw, //+ doesn't work on both
UacMethodHakril, //+ works on both
UacMethodCorProfiler, //+ works on both
UacMethodCMLuaUtil, //+ works on both
UacMethodDccwCOM, //+ works on both
UacMethodDirectoryMock, //+ shows approval window on secure desktop on both
UacMethodShellSdclt, //+ works on both
UacMethodTokenModUiAccess, //+ doesn't work on Canary, but works on 24H2
UacMethodEditionUpgradeMgr, //+ works on both
UacMethodDebugObject, //+ works on both
UacMethodShellChangePk, //+ works on both
UacMethodMsSettings2, //+ works on both
UacMethodNICPoison, //+ works on both
UacMethodIeAddOnInstall, //+ works on both
UacMethodWscActionProtocol, //+ doesn't work on both
UacMethodFwCplLua2, //+ doesn't work on both
UacMethodMsSettingsProtocol,//+ doesn't work on Canary, but works on 24H2
UacMethodMsStoreProtocol, //+ doesn't work on Canary, but works on 24H2
UacMethodPca, //+ doesn't work on Canary, but works on 24H2
UacMethodCurVer, //+ works on both
UacMethodNICPoison2, //+ works on both
UacMethodMsdt, //+ works on both
UacMethodDotNetSerial, //+ doesn't work on both
UacMethodVFServerTaskSched, //+ works on both
UacMethodVFServerDiagProf, //+ works on both
UacMethodIscsiCpl, //+ works on both
UacMethodAtlHijack, //+ works on both
UacMethodSspiDatagram, //+ doesn't work on both
UacMethodTokenModUiAccess2, //+ works on both
UacMethodSXSConsent, //+ doesn't work on both
UacMethodSXSDccw, //+ doesn't work on both
That's fun, because they based on same dotlocal feature, maybe something changed for consent.exe :)
UacMethodSspiDatagram, //+ doesn't work on both
This one need special condition - user account must have password (any, but not a blank). If it still doesn't work - MS fixed it, while it was a relatively new.
Almost everything with *Protocol (UserAssocSet relatives) depends on signatures in Windows dll, current uacme doesn't have 25H2 support.
UacMethodDiskSilentCleanup
This method is confirmed to be fixed by MS in the beginning of 2023, #144