
A Windows feature which can result in bypassing User Group Policy - miles
https://medium.com/tenable-techblog/bypass-windows-10-user-group-policy-and-more-with-this-one-weird-trick-552d4bc5cc1b
======
gruez
_yawn_ yet another case of an "exploit" that involves being other side of an
airtight hatchway[1]. most/all of the important group policy settings are
machine, rather than user. the user group policy settings are mainly with
appearance/styling.

Let's go through each of the "implications".

>Single File Code Execution

If you were able to drop that file, you're either that user, or an
administrator on the computer. If you're that user, you could also achieve
"single file code execution" by dropping a file to the startup folder, or
creating an autorun registry key. If you are an administrator, you already own
the machine.

>Antivirus/EDR Bypass

possibly, although your payload would still have to get pass behavioral
analysis when it's executing.

>Denial of Service

yeah, but you can achieve the same thing by adding "logoff" as an autorun
entry.

[1]
[https://devblogs.microsoft.com/oldnewthing/?p=100665](https://devblogs.microsoft.com/oldnewthing/?p=100665),
or search for that term on the blog, there are multiple entries.

~~~
wolrah
> If you were able to drop that file, you're either that user, or an
> administrator on the computer. If you're that user, you could also achieve
> "single file code execution" by dropping a file to the startup folder, or
> creating an autorun registry key. If you are an administrator, you already
> own the machine.

As I see it the biggest practical issue with this is that it provides a method
for persistence that no user will ever find and even most Windows
administrators will have no idea to look for.

~~~
gruez
>As I see it the biggest practical issue with this is that it provides a
method for persistence that no user will ever find

This isn't relevant because if you're logged in as the affected user, nothing
you see can be trusted because you're already pwned. For instance, the
attacker could have replaced the regedit icon with a patched regedit, or
attached a debugger to every process and patched any system calls. The only
safe course of action would be to create a new profile.

> and even most Windows administrators will have no idea to look for.

AFAIK user hives aren't loaded until they're logged in, in which case they're
subject to the caveats of the previous paragraph. Also, are administrators
really going around and loading each user's registry hive to check for
infections? The only real threat I can think of is antivirus vendors not
knowing about this feature and not scanning the file as a registry hive.

~~~
throwanem
As the article mentions, the threat model here is primarily an insider one,
with a "rogue" user leveraging this method to obtain capabilities the domain
administrator intends to deny. There are certainly more effective exploits for
an outside attacker to use, but that's beside the point.

~~~
dfox
User Group Policy isn't exactly a security mechanism, it exists to prevent
users from unintentionally breaking their profile. There is multitude of ways
how the user in question can inject arbitrary code into processes that are
affected by user group policy as these processes are owned by that user.

------
jve
Is this a real concern?

I always treat User Settings overridable, because they happen either in
security context of user or within user registry which lives in %userprofile%
- the user has full access to ntuser.dat file.

IMHO for real security stuff, Computer Settings are way to go.

> Some exploits may be able to drop a file somewhere on the Windows filesystem
> as non-admin. If the exploit dropped a “%USERPROFILE\ntuser.man”, with an
> autostart registry key to execute a file off of a remote SMB share, then the
> exploit now gained reliable code execution simply by dropping one non-
> executable file.

Well, if malicious guy can write your %USERPROFILE% folder, it's already no-
go. You could potentially plant powershell profile scripts etc.

> By dropping an empty ntuser.man file in %userprofile%, ProfSvc will fail to
> load registry and thus prevent the user from logging in

You've already got bigger problems if someone can write %userprofile%

~~~
ocdtrekkie
I wonder how many sysadmins truly think about User Settings that way. They
should, but I imagine when people are trying to apply a setting to a group of
people, and they feel those permissions should follow them regardless of what
PC they are on, they would just think to make it a user setting.

~~~
GordonS
I work for a mega corp, and many security-related policies are indeed set at
the user, rather than machine, level. Even ones that apply to everyone, no
idea why.

They also enabled the "disable registry editing" policy, but for obvious
reasons this only prevent the official regedit app from running, so anyone
with local admin can edit the registry using a different app.

I feel like I'm pushed in the direction of wasting my time figuring out ways
to bypass what I see as silly restrictions - why would you disable registry
editing for a developer? Why would you force credentials to be entered _every_
time the UAC prompt is shown? The list goes on...

------
userbinator
_Microsoft deemed this to be expected behavior and not a security issue._

For once, thank you for not caving into corporate pressure to make the work
experience even more dystopian... those who have worked in such environments
will known what I'm referring to. (I wonder if their developers themselves
make use of this.)

~~~
Ididntdothis
I rely on several of these “exploits” in order to be able to do my job on my
work machines. I think even IT knows about these tricks but luckily they look
the other way.

~~~
cosmie
Besides the one referenced in the article, any tips (or references) about
those tricks?

~~~
GordonS
I got one I mentioned elsewhere here - if registry editing is disabled, just
use a different registry app (there are some on Github that are better than
the standard one anyway).

Then you can undo group policy settings at will, as long as you know which
registry keys to flip. A good site for this is:

[https://gpsearch.azurewebsites.net](https://gpsearch.azurewebsites.net)

Some settings are set in the local security policy file, rather than in the
registry. From memory, if you have local admin rights you have to specifically
grant your user account full control to the adm files, then you can use the
local security policy MMC snap in to change settings.

Once you change things, they will periodically be set back, which is annoying,
but the tip near the end of the article might work to stop that.

Another tip is to install a dual boot version of Windows on an encrypted
partition, and use that instead of the "official" install. Of course, this
only works if you don't need frequent access to resources on the domain.

------
Spivak
This is actually one of those features that GNOME gets right with dconf
lockdown. You can, on a per setting basis, decide whether users are allowed to
override each setting.

------
amaccuish
Agree with others, yawn. Unplug your computer during login to interrupt the
profile load and be assigned a temporary profile (unless disabled) and you'll
see no user policies applied.

