This post explores how an attacker could leverage the built-in Active Directory management capability called Group Policy and how to mitigate potential security issues.<\/p>\n
<\/p>\n
Group Policy Overview<\/strong><\/h4>\nOne of the key benefits to Active Directory is its management capability and core to this capability is Group Policy. Group Policy has several parts to it and can be challenging to manage in a large enterprise without third-party tools.<\/p>\n
Group Policy enables administrators to manage computers and users in Active Directory.\u00a0 Group Policies are saved as Group Policy Objects (GPOs) which are then associated with Active Directory objects such as sites, domains, or organizational units (OUs). Group Policies can include security options, registry keys, software installation, and scripts for startup and shutdown and domain members refresh group policy settings every 90 minutes by default (5 minutes for Domain Controllers). This means that Group Policy enforces configured settings on the targeted computer.<\/p>\n
In most Active Directory implementations, there is at least one GPO configured on the domain defining mandated password, Kerberos, and domain-wide policies; at least one GPO configured for the Domain Controllers OU; and at least one GPO configured for a servers\u00a0 and workstations OU. These GPOs define security settings specific to the environment and often configure administrative groups, include startup\/shutdown scripts, etc.. GPOs can be configured to set organization-defined security requirements at each level, and can be used for installing software and setting file and registry permissions. GPOs only apply to users and computers and can be filtered with groups or more specifically targeted using the Preferences component.\u00a0 The \u201cNo Override\u201d option ensures that the settings in a Group Policy are applied even if a GPO closer to the resource has contradicting settings.<\/p>\n
There are two Group Policy components:<\/p>\n
1. The “Group Policy Container<\/a>” is stored in Active Directory (<DOMAIN>, System, Policies)<\/p>\n![\"GPO-ADUC-GroupPolicyObject-Attributes\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-ADUC-GroupPolicyObject-Attributes.jpg\")
<\/a><\/p>\n2. The files that actually contain the policy settings (collectively referred to as the “Group Policy Template<\/a>“) are stored in SYSVOL.
\nAll domain Group Policies are stored in the following domain share: \\\\<DOMAIN>\\SYSVOL\\<DOMAIN>\\Policies\\
\n![\"GPO-SYSVOL-Policies\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-SYSVOL-Policies.jpg\")
<\/a><\/p>\nEach Group Policy Object in Active Directory has the following attributes (on the policy object in AD):<\/p>\n
\n- displayName: This is the name given to the GPO by the creator.<\/li>\n
- gPCFileSysPath: This points to the location in SYSVOL where the associated GPO files (aka “Group Policy Template”) are located.<\/li>\n
- gPCMachineExtensionNames: This attribute lists the GPO client side extensions (CSEs) required to by the client process the machine specific Group Policy settings.<\/li>\n
- gPCUserExtensionNames: This attribute lists the GPO client side extensions (CSEs) required to by the client process the user specific Group Policy settings.<\/li>\n<\/ul>\n
Using the PowerShell Active Directory module<\/a> cmdlet “Get-ADObject<\/a>“, we can retrieve key GPO specific attributes for the GPO.<\/p>\n![\"GPO-Policy-Object-Attributes-PowerShell-GetADObject\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-Policy-Object-Attributes-PowerShell-GetADObject.jpg\")
<\/a><\/p>\nThe PowerShell Active Directory module can be easily installed on Windows Server 2008 R2 (and newer) by running the following command in an Administrator PowerShell console:<\/p>\n
Import-module servermanager ; add-windowsfeature rsat-ad-PowerShell<\/em><\/p><\/blockquote>\nAdditionally, every Group Policy has a GPO GUID used to connect GPO components:<\/p>\n
\n- The GPO policy files are stored in a GPO object with the GPO GUID as the name.<\/li>\n
- The Group Policy Template files in SYSVOL are stored in a folder with the GPO GUID as the name.<\/li>\n
- The GPO policy object Distinguished Name is added to the attribute “gPLink” on the Organizational Unit (OU) the GPO is linked to.<\/li>\n<\/ul>\n
When a new GPO is created, it can be created in AD and not linked (in which case, it does nothing), or linked to an OU, domain, or site. Upon creation, a new Group Policy Object is created in the Group Policy Container (<DOMAIN>, System, Policies) and the associated files are created in SYSVOL structure (based on GPO GUID name). When linking a Group Policy to an OU, for example, the OU’s “gPLink” attribute is updated with the GPO’s Distinguished Name. This provides a method for the computer to identify what group policies apply to itself as well as any that apply to logging on user(s).<\/p>\n
Using the PowerShell Active Directory module<\/a> cmdlet “Get-ADOrganizationalUnit<\/a>“, we can retrieve the Group Policies linked to the “Servers” OU.<\/p>\n![\"GPO-OU-LinkedGPOs-PowerShell-GetADOrganizationalUnit\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-OU-LinkedGPOs-PowerShell-GetADOrganizationalUnit.jpg\")
<\/a><\/p>\nSYSVOL <\/a>is the domain-wide share in Active Directory to which all authenticated users have read access. SYSVOL contains logon scripts, group policy data, and other domain-wide data which needs to be available anywhere there is a Domain Controller. The SYSVOL share is automatically synchronized and shared among all Domain Controllers.<\/p>\nWithin this Policies folder are folders for each GPO with the folder name the same as that GPO’s GUID.
\nEach GPO folder in SYSVOL has the following:<\/p>\n
\n- Machine – this folder contains the machine specific settings for the GPO.<\/li>\n
- User – this folder contains the user specific settings for the GPO.<\/li>\n
- GPT.INI – this file contains the configuration settings for the GPO.<\/li>\n<\/ul>\n
![\"GPO-SYSVOL-Policy-Folder-Contents\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-SYSVOL-Policy-Folder-Contents.jpg\")
<\/a><\/p>\nNote that the GPO is tracked in AD via the GPO GUID which has a separate AD object GUID for the AD object. There are a few different reasons for this, and one of the key reasons is to ensure there are predictable GUIDs for specific Group Policy Objects regardless of the Active Directory instance. The “Default Domain Policy” GPO’s GUID is “31B2F340-016D-11D2-945F-00C04FB984F9” and the “Default Domain Controller Policy ” GPO’s GUID is “6AC1786C-016F-11D2-945F-00C04FB984F9” by default.<\/p>\n
In this graphic the ObjectGUID attribute is “0115c3fa-1628-40d0-8a68-2d05530d6f76” which is obviously not the same as the GPO GUID “31B2F340-016D-11D2-945F-00C04FB984F9”.<\/p>\n
![\"GPO-DefaultDomainPolicy-GetADObject-02\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-DefaultDomainPolicy-GetADObject-02.jpg\")
<\/a><\/p>\n <\/p>\n
Group Policy Management<\/strong><\/h4>\nGroup Policy management is often delegated in large enterprises so several different organizations are able to create, modify, and delete Group Policies. This issue with this is that Group Policy quickly gets unruly and difficult to manage since many more than the originally designed (and selected) admins have GPO admin rights. These rights are often delegated at the domain level, so edit (or full) rights apply to all domain GPOs, even those that apply to the Domain (everything) and\/or Domain Controllers.<\/p>\n
The Group Policy Management Console (GPMC) is the primary tool for Group Policy administration and there’s a PowerShell module (GroupPolicy) which is extremely useful for reporting on and backing up GPOs (please backup the domain GPOs regularly) using Backup-GPO<\/a>.<\/p>\n![\"GroupPolicyManagementConsole\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GroupPolicyManagementConsole.jpg\")
<\/a><\/p>\n![\"PowerShell-GroupPolicy-Module-Cmdlets\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/PowerShell-GroupPolicy-Module-Cmdlets.jpg\")
<\/a><\/p>\nGroup Policy Persistence Capability<\/strong><\/h4>\nGroup Policy was designed to provide simplified management of resources in a domain, though its capability can also be co-opted by an attacker to push out malware, create\/modify scheduled tasks, downgrade credential protections<\/a>, add a new local account to all computers that are added to the local Administrators group. and even change existing security policies enabling clear-text password extraction<\/a>.<\/p>\nSome possibilities:<\/p>\n
\n- Configure a PowerShell or VBS script to set group membership at the domain or server level<\/li>\n
- Perform one of the other “Sneaky Persistence Tricks” I outlined previously<\/a>.<\/li>\n
- Running Invoke-Mimikatz<\/a> on all Domain Controllers as SYSTEM every week.<\/li>\n
- Pull the KRBTGT account and then schedule a task that runs DCSync on certain computers throughout the forest using forged Kerberos tickets.<\/li>\n
- Install & Re-install malware on every computer in the Domain\/Forest.<\/li>\n
- Dump all Microsoft LAPS<\/a> passwords for all computer local Administrator accounts by running a PowerShell script automatically on one or all Domain Controllers. There are plenty of options for an attacker once Group Policy is part of their toolkit.<\/li>\n<\/ul>\n
In fact, the Mandiant M-Trends 2016 report <\/a>covering activity in 2015 includes information about how attackers are leveraging Group Policy to deploy malware:<\/p>\n![\"Mandiant-MTrends2016-GPO-Persistence\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/Mandiant-MTrends2016-GPO-Persistence.jpg\")
<\/a><\/p>\nNote that the person who hacked Haking Team leveraged Group Policy as part of the hack: http:\/\/pastebin.com\/raw\/0SNSvyjJ<\/a><\/strong>
\n<\/span><\/p>\n
\nRed Team Note on Group Policy:<\/span>
\nThe default Group Policy application behavior is to “refresh the group policy” on the client, though this doesn’t actually mean the GPO settings are re-applied. By default, the GPO’s settings are only reapplied if the GPO was modified prior to the refresh. This means that one could reverse a GPO enforced setting via the computer’s registry (typically with admin rights) and the unauthorized setting remains until the GPO is modified, after which the GPO settings are re-applied.<\/p>\nBlue Team Defenses:<\/span>
\nAfter testing, change the Group Policy default setting to re-apply GPO settings at every refresh (Process even if the Group Policy objects have not changed). This does have a potential performance hit on the client, but will ensure all GPO enforced settings are re-applied.<\/p>\nComputer Configuration, Policies, Administrative Templates, System, Group Policy, Configure security policy processing<\/em>: Set to Enabled.
\nAlso check the box for “Process even if the Group Policy objects have not changed<\/em>”<\/p>\nIt’s also recommended to configure the same settings for each of the following:<\/p>\n
\n- Computer Configuration, Policies, Administrative Templates, System, Group Policy, Configure registry policy processing<\/em><\/li>\n
- Computer Configuration, Policies, Administrative Templates, System, Group Policy, Configure scripts policy processing<\/em><\/li>\n
- As well as any other policy settings as needed.<\/li>\n<\/ul>\n
![\"GPO-Enforce\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-Enforce.jpg\")
<\/a><\/p>\n <\/p>\n
Group Policy Exploit Capability<\/strong><\/h4>\nThough this post focuses on retaining domain-level privileged access (“Domain Admin” rights), there are several ways in which an existing organization’s Group Policy configuration could be used to escalate access. The obvious method is to exploit existing Group Policy Preference credentials<\/a> in the environment which enables an attacker to escalate access from domain user to server\/application\/OU admin, or even Domain Admin. The less obvious method involves finding GPOs linked at either the domain or a top level OU with custom security settings.<\/p>\nBased on AD security assessments I have performed<\/a>, I’ve found that organizations frequently have GPOs linked at a high level with custom security settings providing edit rights to accounts that are not Active Directory Administrators. This provides an avenue for privilege escalation since the GPO can be reconfigured to run a script or change security.<\/p>\nPowerView<\/a>, now integrated into PowerSploit<\/a>, includes some interesting Group Policy enumeration capability via PowerShell.<\/p>\nThe following example shows a Group Policy called “Full Auditing Policy” linked at the Domain level which has “Edit settings” rights delegated to the “Han Solo” (Server Admin) account.<\/p>\n
![\"GPO-Domain-GroupPolicy-Security-Delegation-NonDA\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-Domain-GroupPolicy-Security-Delegation-NonDA.jpg\")
<\/a><\/p>\nHan Solo is a member of the “Server Admins” group which is not a domain admin group.<\/p>\n
![\"GPO-HanSolo-GetADUser-Prop-MemberOf\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-HanSolo-GetADUser-Prop-MemberOf.jpg\")
<\/a><\/p>\nSince Han Solo has the rights to edit this domain linked GPO, let’s modify it.<\/p>\n
![\"GPO-Domain-GroupPolicy-Exploit-ScheduledTask\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-Domain-GroupPolicy-Exploit-ScheduledTask.jpg\")
<\/a><\/p>\nAfter editing the Group Policy, this GPO will now add a scheduled task on every computer in the domain, enabling any type of activity the attacker wishes.<\/p>\n
<\/p>\n
“Hidden Group Policy” – Group Policies Applied to Sites
\n<\/strong><\/h4>\nWe know that Group Policy is typically applied to Organizational Units and we can easily view them in GPMC.<\/p>\n
![\"GPO-GPMC-01\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-GPMC-01.jpg\")
<\/a><\/p>\nHowever, many admins don’t realize that while it is not best practice to link Group Policies to sites, there’s nothing preventing a Domain Admin (Enterprise Admin) from doing so.<\/p>\n
All that’s needed is to select the AD sites that should be shown in the Group Policy Management Console and link the new\/updated Group Policies to the site(s)<\/p>\n
![\"GPO-GPMC-ShowSites\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-GPMC-ShowSites.jpg\")
<\/a><\/p>\nLooking at GPMC, we can see there are two Group Policies linked to the HQ Site and both of them were last modified recently (hint, hint).<\/p>\n
![\"GPO-GPMC-New-GPOs-Linked-To-Site-02\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/GPO-GPMC-New-GPOs-Linked-To-Site-02.jpg\")
<\/a><\/p>\nWould your current monitoring system notify on this change?<\/em><\/h5>\n <\/p>\n
Mitigation<\/strong><\/h4>\nAll Group Policies in the AD environment should be configured for a single purpose and monitored for unauthorized modification, especially GPOs linked to the domain, Domain Controllers OU, and\/or a top level OU such as workstations, servers, admins, etc.<\/p>\n
Delegated permissions to Group Policy should be reviewed on a regular basis, especially those linked to top-level OUs. Only Active Directory administrators should have modify rights to GPOs applied to the domain, top-level OUs, and any GPOs linked to critical assets (Domain Controllers, servers, admin computers, etc).<\/p>\n
Additionally, all sites should be reviewed for linked Group Policies since these GPOs can cross domain boundaries enabling privilege escalation across domains in the same AD forest.<\/p>\n
SYSVOL permissions are critical and must remain the same as the default settings since SYSYOL contains the actual Group Policy settings in files that are applied by GPO clients. If a GPO configuration file has permissions that enables some on who is not an Active Directory admin to change the file, and thus change what action the GPO client actually performs, an attacker could quickly escalate permissions up to Domain Admin level.<\/p>\n
Resources<\/strong><\/h4>\n\n- Group Policy Basics \u2013 Part 1: Understanding the Structure of a Group Policy Object<\/a><\/li>\n
- Local Group Enumeration using PowerView (includes Group Policy features)<\/a><\/li>\n
- Configure a Scheduled Task<\/a><\/li>\n
- Group Policy Preferences<\/a><\/li>\n
- Exploit existing Group Policy Preference credentials<\/a><\/li>\n
- Complete list of Sneaky Active Directory Persistence Tricks posts <\/a><\/li>\n<\/ul>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
The content in this post describes a method through which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for about 5 minutes. Complete list of Sneaky Active Directory Persistence Tricks posts This post explores how an attacker could leverage the built-in Active Directory management capability called Group Policy … <\/p>\n
2. The files that actually contain the policy settings (collectively referred to as the “Group Policy Template<\/a>“) are stored in SYSVOL. Each Group Policy Object in Active Directory has the following attributes (on the policy object in AD):<\/p>\n Using the PowerShell Active Directory module<\/a> cmdlet “Get-ADObject<\/a>“, we can retrieve key GPO specific attributes for the GPO.<\/p>\n The PowerShell Active Directory module can be easily installed on Windows Server 2008 R2 (and newer) by running the following command in an Administrator PowerShell console:<\/p>\n Import-module servermanager ; add-windowsfeature rsat-ad-PowerShell<\/em><\/p><\/blockquote>\n Additionally, every Group Policy has a GPO GUID used to connect GPO components:<\/p>\n When a new GPO is created, it can be created in AD and not linked (in which case, it does nothing), or linked to an OU, domain, or site. Upon creation, a new Group Policy Object is created in the Group Policy Container (<DOMAIN>, System, Policies) and the associated files are created in SYSVOL structure (based on GPO GUID name). When linking a Group Policy to an OU, for example, the OU’s “gPLink” attribute is updated with the GPO’s Distinguished Name. This provides a method for the computer to identify what group policies apply to itself as well as any that apply to logging on user(s).<\/p>\n Using the PowerShell Active Directory module<\/a> cmdlet “Get-ADOrganizationalUnit<\/a>“, we can retrieve the Group Policies linked to the “Servers” OU.<\/p>\n SYSVOL <\/a>is the domain-wide share in Active Directory to which all authenticated users have read access. SYSVOL contains logon scripts, group policy data, and other domain-wide data which needs to be available anywhere there is a Domain Controller. The SYSVOL share is automatically synchronized and shared among all Domain Controllers.<\/p>\n Within this Policies folder are folders for each GPO with the folder name the same as that GPO’s GUID. Note that the GPO is tracked in AD via the GPO GUID which has a separate AD object GUID for the AD object. There are a few different reasons for this, and one of the key reasons is to ensure there are predictable GUIDs for specific Group Policy Objects regardless of the Active Directory instance. The “Default Domain Policy” GPO’s GUID is “31B2F340-016D-11D2-945F-00C04FB984F9” and the “Default Domain Controller Policy ” GPO’s GUID is “6AC1786C-016F-11D2-945F-00C04FB984F9” by default.<\/p>\n In this graphic the ObjectGUID attribute is “0115c3fa-1628-40d0-8a68-2d05530d6f76” which is obviously not the same as the GPO GUID “31B2F340-016D-11D2-945F-00C04FB984F9”.<\/p>\n <\/p>\n Group Policy management is often delegated in large enterprises so several different organizations are able to create, modify, and delete Group Policies. This issue with this is that Group Policy quickly gets unruly and difficult to manage since many more than the originally designed (and selected) admins have GPO admin rights. These rights are often delegated at the domain level, so edit (or full) rights apply to all domain GPOs, even those that apply to the Domain (everything) and\/or Domain Controllers.<\/p>\n The Group Policy Management Console (GPMC) is the primary tool for Group Policy administration and there’s a PowerShell module (GroupPolicy) which is extremely useful for reporting on and backing up GPOs (please backup the domain GPOs regularly) using Backup-GPO<\/a>.<\/p>\n Group Policy was designed to provide simplified management of resources in a domain, though its capability can also be co-opted by an attacker to push out malware, create\/modify scheduled tasks, downgrade credential protections<\/a>, add a new local account to all computers that are added to the local Administrators group. and even change existing security policies enabling clear-text password extraction<\/a>.<\/p>\n Some possibilities:<\/p>\n In fact, the Mandiant M-Trends 2016 report <\/a>covering activity in 2015 includes information about how attackers are leveraging Group Policy to deploy malware:<\/p>\n Note that the person who hacked Haking Team leveraged Group Policy as part of the hack: http:\/\/pastebin.com\/raw\/0SNSvyjJ<\/a><\/strong> Blue Team Defenses:<\/span> Computer Configuration, Policies, Administrative Templates, System, Group Policy, Configure security policy processing<\/em>: Set to Enabled. It’s also recommended to configure the same settings for each of the following:<\/p>\n <\/p>\n Though this post focuses on retaining domain-level privileged access (“Domain Admin” rights), there are several ways in which an existing organization’s Group Policy configuration could be used to escalate access. The obvious method is to exploit existing Group Policy Preference credentials<\/a> in the environment which enables an attacker to escalate access from domain user to server\/application\/OU admin, or even Domain Admin. The less obvious method involves finding GPOs linked at either the domain or a top level OU with custom security settings.<\/p>\n Based on AD security assessments I have performed<\/a>, I’ve found that organizations frequently have GPOs linked at a high level with custom security settings providing edit rights to accounts that are not Active Directory Administrators. This provides an avenue for privilege escalation since the GPO can be reconfigured to run a script or change security.<\/p>\n PowerView<\/a>, now integrated into PowerSploit<\/a>, includes some interesting Group Policy enumeration capability via PowerShell.<\/p>\n The following example shows a Group Policy called “Full Auditing Policy” linked at the Domain level which has “Edit settings” rights delegated to the “Han Solo” (Server Admin) account.<\/p>\n Han Solo is a member of the “Server Admins” group which is not a domain admin group.<\/p>\n Since Han Solo has the rights to edit this domain linked GPO, let’s modify it.<\/p>\n After editing the Group Policy, this GPO will now add a scheduled task on every computer in the domain, enabling any type of activity the attacker wishes.<\/p>\n <\/p>\n We know that Group Policy is typically applied to Organizational Units and we can easily view them in GPMC.<\/p>\n However, many admins don’t realize that while it is not best practice to link Group Policies to sites, there’s nothing preventing a Domain Admin (Enterprise Admin) from doing so.<\/p>\n All that’s needed is to select the AD sites that should be shown in the Group Policy Management Console and link the new\/updated Group Policies to the site(s)<\/p>\n Looking at GPMC, we can see there are two Group Policies linked to the HQ Site and both of them were last modified recently (hint, hint).<\/p>\n <\/p>\n All Group Policies in the AD environment should be configured for a single purpose and monitored for unauthorized modification, especially GPOs linked to the domain, Domain Controllers OU, and\/or a top level OU such as workstations, servers, admins, etc.<\/p>\n Delegated permissions to Group Policy should be reviewed on a regular basis, especially those linked to top-level OUs. Only Active Directory administrators should have modify rights to GPOs applied to the domain, top-level OUs, and any GPOs linked to critical assets (Domain Controllers, servers, admin computers, etc).<\/p>\n Additionally, all sites should be reviewed for linked Group Policies since these GPOs can cross domain boundaries enabling privilege escalation across domains in the same AD forest.<\/p>\n SYSVOL permissions are critical and must remain the same as the default settings since SYSYOL contains the actual Group Policy settings in files that are applied by GPO clients. If a GPO configuration file has permissions that enables some on who is not an Active Directory admin to change the file, and thus change what action the GPO client actually performs, an attacker could quickly escalate permissions up to Domain Admin level.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" The content in this post describes a method through which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for about 5 minutes. Complete list of Sneaky Active Directory Persistence Tricks posts This post explores how an attacker could leverage the built-in Active Directory management capability called Group Policy … <\/p>\n<\/a><\/p>\n
\nAll domain Group Policies are stored in the following domain share: \\\\<DOMAIN>\\SYSVOL\\<DOMAIN>\\Policies\\
\n<\/a><\/p>\n\n
<\/a><\/p>\n\n
<\/a><\/p>\n
\nEach GPO folder in SYSVOL has the following:<\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\nGroup Policy Management<\/strong><\/h4>\n
<\/a><\/p>\n<\/a><\/p>\nGroup Policy Persistence Capability<\/strong><\/h4>\n
\n
<\/a><\/p>\n
\n<\/span><\/p>\n
\nRed Team Note on Group Policy:<\/span>
\nThe default Group Policy application behavior is to “refresh the group policy” on the client, though this doesn’t actually mean the GPO settings are re-applied. By default, the GPO’s settings are only reapplied if the GPO was modified prior to the refresh. This means that one could reverse a GPO enforced setting via the computer’s registry (typically with admin rights) and the unauthorized setting remains until the GPO is modified, after which the GPO settings are re-applied.<\/p>\n
\nAfter testing, change the Group Policy default setting to re-apply GPO settings at every refresh (Process even if the Group Policy objects have not changed). This does have a potential performance hit on the client, but will ensure all GPO enforced settings are re-applied.<\/p>\n
\nAlso check the box for “Process even if the Group Policy objects have not changed<\/em>”<\/p>\n\n
<\/a><\/p>\nGroup Policy Exploit Capability<\/strong><\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n“Hidden Group Policy” – Group Policies Applied to Sites
\n<\/strong><\/h4>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nWould your current monitoring system notify on this change?<\/em><\/h5>\n
Mitigation<\/strong><\/h4>\n
Resources<\/strong><\/h4>\n
\n