Some thought about upcoming Windows 10 Fall update aka "Fail update".
Starting from earlier TH2 builds (I don't really document all changes), probably from 1054x UAC service AppInfo has been updated with countermeasures against UAC bypass method implemented in malware known as Zlader/H1N1 loader which main idea you can find implemented in UACMe as Method 10. This and some other changes related to UAC strengthening - the biggest update to UAC since Windows 7 release. You will never read about this anywhere in Microsoft "changelogs" - they all full of fuck about Start button and "nobodycares" Edge (no joke).
Now before autoelevating UAC examines application full path to include trusted directory (system32/syswow64) with two exceptions:
Code: Select allsysprep.exe
inetmgr.exe (part of IIS)
they both are special cases and hardcoded with their path
Code: Select allsystem32\sysprep\sysprep.exe
system32\inetsrv\inetmgr.exe
inetmgr.exe doesn't exists in default setup (this application exist only when IIS component installed).
Windows 10 TH2 comfortable UAC bypass
Requrements:
1) AutoElevated application must be MS and signed. Lot of candidates inside Windows 10 itself.
2) User must be an Admin. Default setup gives you it.
3) IIS not installed. Just like with default setup.
And we have a lot of candidates. But I like GWXUXWorker.exe backdoor from "Get Windows 10" crapware advertising. It is signed by embedded signature, it is autoelevated and it is not protected by manifest.
1) Copy GWXUXWorker.exe under name inetmgr.exe to system32\inetsrv folder.
2) Put payload SLC.dll near it.
3) Start inetmgr.exe
P.S.
Some Bonus:
Microsoft design of OS.
During 8/8.1 development process sysprep.exe got update for it manifest - to counteract dll hijacking used for UAC bypass, a LoadFrom instruction for the Windows loader. However they were unable to block dll hijacking completely and starting from Windows 10 moved some of required and shared dlls to the KnownDll -> bcryptPrimitives.dll, shcore.dll ... and with 10240 release added
another uncontrolled dependency to the sysprep.exe -> dbgcore.dll. Yep fixing one bypass they added new. During Windows 10 TH2 development circle they seems finally managed to figure out what they did and updated sysprep manifest again - to include this new dependency - dbgcore.dll.
Now look on the manifest
Code: Select all <!--
Specifically load these DLLs from the specified path. This
is done as a defence-in-depth approach to closing a known UAC
exploit related to Sysprep.exe being auto-elevated. The list
need not contain KnownDlls since those are always loaded
by the loader from the system directory.
-->
<file
loadFrom="%systemroot%\system32\actionqueue.dll"
name="actionqueue.dll"
/>
<file
loadFrom="%systemroot%\system32\bcryptprimitives.dll"
name="bcryptprimitives.dll"
/>
<file
loadFrom="%systemroot%\system32\cryptbase.dll"
name="cryptbase.dll"
/>
<file
loadFrom="%systemroot%\system32\dbgcore.dll"
name="dbgcore.dll"
/>
<file
loadFrom="%systemroot%\system32\unattend.dll"
name="unattend.dll"
/>
<file
loadFrom="%systemroot%\system32\wdscore.dll"
name="wdscore.dll"
/>
"The list need not contain KnownDlls since those are always loaded"
Wasn't bcryptprimitives.dll in Windows 10 KnownDlls?
Yes it is.
I don't really know how they manage this now, but I see it as "oh fuck lets write some line here and forget about it".
Next one example is ISecurityEditor - undocumented inteface which was used by malware Simda for about 4+ years to bypass UAC. They key feature of this interface - it is autoelevated and contain methods that can be used to set security of objects. For example you can change access for the registry keys inside HKLM doing this from middle integrity level - simple running from desktop without elevation. SecurityEditor itself implemented inside shell32 and key methods of it GetSecurity/SetSecurity are wrappers for SetNamedSecurityInfoW/GetNamedSecurityInfoW. Starting from 10136 Microsoft broke this interface design logic, however leaving it declaration unchanged. As you can guess they added one line of code fix - an "IF" and changed SetNamedSecurityInfoW call parameter, forcing this wrapper work only with file objects.
And you can see such attitude almost for EVERYTHING in this OS, starting from GUI design and ending kernel mode components. Do not like our recyclebin icon made in pbrush? Ok - we have refreshed Windows 98 recyclebin icon for you.
In 10061 they introduced new kernel object named "Silo" - sort of process isolation feature. They implemented user mode support for it - set of native API functions to create and manipulate Silo objects. But it turned out that this feature is insecure, for example see
https://code.google.com/p/google-securi ... ail?id=459. And in 10240 release this API set was removed from ntdll, however kernel object still exist, now with TH2 release Silo object removed too. So this feature is strictly kernel mode implemented part of Windows.
Despite the fact this OS version will bring the most "secured" UAC version since Vista time I wouldn't recommend install or use it.