Supposedly fixed in Win 10 Creators Update. https://threatpost.com/fileless-uac-bypass-uses-windows-backup-and-restore-utility/124579/ -EDIT- Again, setting UAC to max. level prevents auto-elevation.
Here's a nifty little program: http://www.nirsoft.net/utils/advanced_run.html that can just be downloaded, run, and works on any Win ver.. It allows elevation from a standard user account to System level. The feature I like is the ability to perform code injection on any executing process by creation a spawned child process:
Here is an interesting paper about ways how to bypass UAC: https://labs.mwrinfosecurity.com/publications/uac-0day-all-day/
We used to be "relatively" safe with UAC set to Max but the suggestion now is that even that is no good with a split token Admin account which is typical. Standard User Account is the only way to go these days. Even Protected Processes have been defeated within the past six months.
Certainly. Link: https://twitter.com/aionescu/status/912719937839468549 Link: https://twitter.com/aionescu/status/902368288021164033 Link: https://twitter.com/tiraniddo/status/912725507401179137 Detailed bug report: https://bugs.chromium.org/p/project-zero/issues/detail?id=1336 As I understand it, it was James Forshaw's wizardry that got this ball rolling while Alex Ionescu took it a step further via "get code execution inside a PPL, even a Windows TCB level PPL, from a normal user without needing admin by requesting a protected process in CreateProcess". If anyone does not already follow Google's James Forshaw, definitely add him to your list of security mentors to follow. But anyways, this is bad because Windows Defender is protected by (Protected Process-Light) PPL, as is LSASS. Other antimalware engines may use that protection as well particularly for ELAM drivers, if I recall correctly. Alex Ionescu previously had spoken very highly of PPL up until just recently, of course. Microsoft is now saying that PPL is "not a security boundary" similar to UAC bypasses.
Thanks. I will check out the articles when I get a chance. As far as lsass.exe on Win 10 CE plus WD and any AV vendors that also use the ELAM driver, it's not so much that they are running in protected mode as they are running in kernel protected mode. So if they is a vulnerability in that status, all is pretty much lost as far as Win security goes. What the ELAM driver allows for is the loading of the AV kernel process prior to the loading of any other application mode drivers. You can verify this by enabling boot logging. The vulnerability is and always has been the following. If malware can create a malicious device driver for example or modify the default driver loading order, it can have its driver load prior to the ELAM driver. It can then use the malware driver to intercept the loading of any subsequent drivers; namely the ELAM driver loading the AV kernel process into the OS kernel.
Ok. This GitHub POC explains a lot: https://github.com/Mattiwatti/PPLKiller And how he gets around Win 10 CE code signing protection: Nice! However, do note the installation requirements. I assume most are by now monitoring bcdedit and sc execution. Also copying to the drivers directory requires elevated privledges: The main question is "what code signing functionality disabling" is being employed? Obviously, this is a major Win 10 CE vulnerability.
I believe this is something that James Forshaw had also talked about in a 4-part blog series that was more oriented toward Windows 10 S and the code signing policies involved there. I don't recall all of the finer details though as to whether or not he divulged the vuln in detail or not. Link: https://tyranidslair.blogspot.ca/2017/07/device-guard-on-windows-10-s_20.html Link: https://tyranidslair.blogspot.ca/2017/07/dg-on-windows-10-s-executing-arbitrary.html Link: https://tyranidslair.blogspot.ca/2017/08/copy-of-device-guard-on-windows-10-s.html Link: https://tyranidslair.blogspot.ca/2017/08/dg-on-windows-10-s-abusing-installutil.html I am not as familiar with Windows 10 CE though but assume that the policies or policy structures could very well be similar dependent upon the vulnerability.
Standard user account will not prevent a UAC bypass by a dedicated hacker. Simply because select Win processes can auto-elevate SUA accounts. Discussed in this thread: https://malwaretips.com/threads/uac...ivileges-works-on-all-windows-versions.62555/
If account is not a member of any "administrators" group, they can not auto-elevate. This is not preventing UAC bypass, because there is no UAC involved, because this user account simply doesn't have any administrative privileges, so there is nothing to be controlled by UAC.
I went through these and overall they can best be summed up by the following excerpt from the above first link: As is past APT attacks if you're targeted, you're pretty much "dead meat." Of note for DG users is this mitigation by the same author: http://www.exploit-monday.com/2016/09/using-device-guard-to-mitigate-against.html As far as bypassing kernel mode code signing integrity, the only way that can be done is by employing another kernel mode driver to do so as previously posted. So we've come pretty much "full circle" to what has been a fundamental Windows security problem since "day one." That is kernel mode driver security. With the mitigation being what it always has been which is monitoring driver creation.
OK. This one is a problem: https://bugs.chromium.org/p/project-zero/issues/detail?id=1336 So it's back to protecting lsass.exe and my AV kernel process against any code injection using its HIPS.
Here is a great primer on elevating user privileges: Windows Privilege Escalation Fundamentals http://www.fuzzysecurity.com/tutorials/16.html Here a just a few extracts of the "techniques" from the article:
In regards to disabling PPL that was noted in reply #9, here is how it is done with the example shown disabling PPL for Windows Defender ATP: https://twitter.com/retBandit/status/901477187022233600 -EDIT- The author also noted there are other easier ways to "neuter" Win Defender ATP:
As far as disabling PPL, it is somewhat of a "moot point" now that Casey Smith has come up with a way to MS code sign Mimikatz as I posted here: https://www.wilderssecurity.com/threads/ms-signed-mimikatz-in-just-3-steps.397004/. Save yourself the hassle and just inject Mimikatz into a PPL process.
