4 ms·

A Windows feature which can result in bypassing User Group Policy

75 points by miles 7y ago

userbinator 7y ago
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.)
- use-net 7y ago
  any MS dude with a brain already uses Linux whenever possible.
- Ididntdothis 7y ago
  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 7y ago
    Besides the one referenced in the article, any tips (or references) about those tricks?
    - GordonS 7y ago
      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.
    - Ididntdothis 7y ago
      Most of them come down to elevating yourself through another tool so you can do what you need to. Think about things like SQL server or BeyondTrust. Working with pen testers helps a lot to get ideas :)
  - jon-wood 7y ago
    I’d highly recommend not doing this, you’re giving ammunition should you ever find yourself in a situation where someone would like to fire you but doesn’t have a solid cause. As painful as it is if you’re unable to do your job because of IT policies escalate it up the management chain.
    - Ididntdothis 7y ago
      I think I know what I am doing and I have backing from management. A lot of people do the same thing. Our choice is to either to not being able to work or do these hacks. If it were up to corporate IT we couldn’t do our job.
jve 7y ago
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 7y ago
  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 7y ago
    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...
- Dylan16807 7y ago
  > the user has full access to ntuser.dat file How so? It's always open and locked when you're logged in, isn't it?
gruez 7y ago
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 7y ago
  > 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 7y ago
    >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.
amaccuish 7y ago
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.
Spivak 7y ago
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.

75 points by miles 7y ago

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.)

use-net 7y ago
any MS dude with a brain already uses Linux whenever possible.
Ididntdothis 7y ago
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 7y ago
  Besides the one referenced in the article, any tips (or references) about those tricks?
  - GordonS 7y ago
    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.
  - Ididntdothis 7y ago
    Most of them come down to elevating yourself through another tool so you can do what you need to. Think about things like SQL server or BeyondTrust. Working with pen testers helps a lot to get ideas :)
- jon-wood 7y ago
  I’d highly recommend not doing this, you’re giving ammunition should you ever find yourself in a situation where someone would like to fire you but doesn’t have a solid cause. As painful as it is if you’re unable to do your job because of IT policies escalate it up the management chain.
  - Ididntdothis 7y ago
    I think I know what I am doing and I have backing from management. A lot of people do the same thing. Our choice is to either to not being able to work or do these hacks. If it were up to corporate IT we couldn’t do our job.

jve 7y ago

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 7y ago
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 7y ago
  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...
Dylan16807 7y ago
> the user has full access to ntuser.dat file How so? It's always open and locked when you're logged in, isn't it?

gruez 7y ago

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 7y ago
> 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 7y ago
  >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.

amaccuish 7y ago

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.

Spivak 7y ago

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.