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.)
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.
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:
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.
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.
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.
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%
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.
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...
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.
> 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.
>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.
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.
>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
What would be those capabilities? They'd have to be user-level policies, which already limits what you could do.
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.
I think the main takeaway is this: "it is more likely a threat from a rogue Domain User trying to break out of restrictions imposed by a Domain Admin."
Another way of phrasing this is "it's a way for overly restricted developers to make some minor modifications on their machine to actually get some work done."
I could have really used this trick when I worked at a large corporation with a locked-down environment...
Just from a consistency perspective the fact that you can prevent the Group Policy Client from overriding your hacked hive is disturbing to me.
If the report said "everything you did here will be wiped out the next time gpc syncs with the domain controller", I'd be inclined to laugh it off as well.
The whole exploit relies on the non admin user being able to run regedit.exe - every sane lockdown policy blocks the execution of this application by non-admins as a matter of course. If you are not locking regedit.exe down, then you might as well just throw all your policies out of the window.
Again, how would you get the mandatory profile file onto the work machine? re-enforcing my original point, if the USBs ports are open, or email attachments aren't being filtered, you've blown your desktop security anyway.
I did this stuff as my job for 10 years. Windows XP was like swiss cheese, Windows 7 was much better, and now Windows 10 is rock solid; if you go all out on the security settings, an average user cannot break in or elevate themselves.
Your yawn is way too dismissive, since what you're dismissing includes many of the settings themselves.
If none of those policies were supposed to be enforced in the first place, then that's a notable failing on Microsoft's end. Not the bypass being boring.
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.
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.
27 comments
[ 3.0 ms ] story [ 62.1 ms ] threadFor 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.)
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
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.
Working with pen testers helps a lot to get ideas :)
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%
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...
How so? It's always open and locked when you're logged in, isn't it?
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, or search for that term on the blog, there are multiple entries.
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.
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.
What would be those capabilities? They'd have to be user-level policies, which already limits what you could do.
Another way of phrasing this is "it's a way for overly restricted developers to make some minor modifications on their machine to actually get some work done."
I could have really used this trick when I worked at a large corporation with a locked-down environment...
If the report said "everything you did here will be wiped out the next time gpc syncs with the domain controller", I'd be inclined to laugh it off as well.
I did this stuff as my job for 10 years. Windows XP was like swiss cheese, Windows 7 was much better, and now Windows 10 is rock solid; if you go all out on the security settings, an average user cannot break in or elevate themselves.
If none of those policies were supposed to be enforced in the first place, then that's a notable failing on Microsoft's end. Not the bypass being boring.