Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 179
  • Last Modified:

Mitigation for Win 10 user account bypass

How can we mitigate or work around the above?
7 Solutions
I analysed that and I cannot even confirm any form of danger.
1) I started the task and monitored the %temp% folder using NTFS auditing - nothing gets written into it!
2) I looked at the task and it executes as weak user. "run with elevated/high integrity privileges" does not mean, the task is running like that, but only that it may run like that if the user executing it is an administrator.
So unless these researchers have totally different win10 systems than I have, their assumptions are plain wrong. Surely, it may be that the process cleanmgr.exe does indeed load dlls without verifying those, but
A not with high privileges
B not from the folder they indicate it does.
C if so, nothing is won. If the attacker may write files to user directories, he already has the same privileges as the user and is acting in his name.

I see no problem at all.
Dustin SaundersDirector of OperationsCommented:
You can test with their code to confirm the problem.  But it's honestly no different than the thousand other ways viruses get planted into a system, and you likely need to be infected already in order for something to execute that dll swap.

Short answer is disable the task.  But, I'd imagine despite Windows not adding an OS patch to it (I agree with why), a listener may show up in Win Defender or in other AV's active protection fairly soon.
btanExec ConsultantCommented:
The mean is to prevent the infection to be even be successful...and detected early as possible and not rely solely on AV or HIPS only. We must ask ourselves if those baseline is bypass including the UAC, AV and HIPS, what other layer of defence still exist to block the infection attempts.
- Fundamental readily patch as usual as nothing beats closing up the holes available to be exploit
- application whitelisting using cryptoprevent or applocker or SecureAPlus to restrict only few s/w to run
- run another exploit watch dog like EMET to minimally deter the infection from going further where it attempts to skip UAC and ASLR and activate the Return-oriented exploit codes gadgets
- check for dll hijacking attempts (supposedly HIPS should handle that)
I have been experimenting with a new methodology (well, at least it's new to me!) for detecting active attacks of this nature on vulnerable systems, and have written a program which does the following:

-Iterate through each running process on the system, identifying all the DLLs which they have loaded
-For each DLL, inspect all the locations where a malicious DLL could be placed
-If a DLL with the same name appears in multiple locations in the search order, perform an analysis based on which location is currently loaded and highlight the possibility of a hijack to the user
-Additionally: Check each DLL to see whether it has been digitally signed, and give the user the option to ignore all signed DLLs to prevent any appls load a malicious library (allowing for the execution of arbitrary code) that is placed a at a preferential location as dictated by the Dynamic-Link Library Search Order which is a pre-defined standard on how Microsoft Windows searches for a DLL when the path has not been specified by the developer.
- disable unnecessary services like Powerscript, WMI, python based or macro based in Document appls, end user do not really need those to work and likely it is used for administrative patch but go based on Windows push update instead of running batch job with script.
Building an Effective Phishing Protection Program

Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.

@Dustin: sorry, but it never even works here, not at work, nor at home, not as restricted user, not as administrator, not even elevated.
Invoke-UACBypass -DllPath C:\Users\Me\Desktop\viasetup.dll -Verbose
VERBOSE: SilentCleanup task executed successfully. Message: SUCCESS: Attempted to run the scheduled task "\Microsoft\Windows\DiskCleanup\SilentCleanup".
Invoke-UACBypass : UAC bypass failed. The DLL was not planted in its target.
At line:1 char:1
+ Invoke-UACBypass -DllPath C:\Users\Me\Desktop\viasetup.dll -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-UACBypass

Open in new window

And even if: what it does is execute code with the highest privs a user could get. So if your user is a restricted user, so what? if he's an admin, why does he execute such code? He should know better.
I see the meaning of the exploit, sure it's something, but A it does not work here and B I would not care if it does. UAC is not meant to protect me, it never was. Quote Microsoft:
A weakness that would allow to bypass the “Consent Prompt” is not considered a security vulnerability, since that is not considered a security boundary.
(source: )
Dustin SaundersDirector of OperationsCommented:
PS C:\Users\dustin> Invoke-UACBypass -DllPath C:\test\fake.dll -Verbose
VERBOSE: SilentCleanup task executed successfully. Message: SUCCESS: Attempted to run the scheduled task "\Microsoft\Windows\DiskCleanup\SilentCleanup".
VERBOSE: DismHost folder created in c:\users\dustin\appdata\local\temp\fe314b08-f309-454b-8b93-f9815ec653af
VERBOSE: C:\test\fake.dll to c:\users\dustin\appdata\local\temp\fe314b08-f309-454b-8b93-f9815ec653af\LogProvider.dll
VERBOSE: UAC bypass was successful!

Open in new window

Confirmed on my system.  Maybe you have AV interfering or something.
No AV but defender. SRP and applocker deactivated for the test.
Deactivated defender - no change.
Adam BrownSr Solutions ArchitectCommented:
@McKnife, the DLL you use has to match the architecture of the exploited DLL.

This particular issue, as mentioned, is only a problem when the logged in user has Administrative privileges. It won't work with a non-privileged user, because those users don't have permission to overwrite the .dll file in question (which is required for this to work).

That said, the easy fix for this problem is to disable or remove the scheduled task. The task is there to automate system disk cleanup, and that isn't really necessary. If you're really worried about this issue, just shut down the task. You should be able to do so with Group Policy Preferences.
No, I tried both architectures, no difference. Maybe it is language aware (=badly coded ;-) and will only work on native en-us systems?

Whatever, the point should have become clear: the task does no magic, no user is turned to malicious admin here. And to exploit an admin, well, if you make him execute your code is already too much, so we can conclude this is not too dangerous. If you think you can do without that task, disable it. It is not needed if you have no disk space problems, so disable it.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now