{
	"id": "f2fd57e6-66ab-40b1-b467-262948665c1b",
	"created_at": "2026-04-06T00:18:09.03804Z",
	"updated_at": "2026-04-10T03:20:44.582607Z",
	"deleted_at": null,
	"sha1_hash": "c481b5b19a37f62abfbcc0c315c479667acc1524",
	"title": "Sneaky Active Directory Persistence #17: Group Policy",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1583991,
	"plain_text": "Sneaky Active Directory Persistence #17: Group Policy\r\nBy Sean Metcalf\r\nPublished: 2016-03-14 · Archived: 2026-04-05 18:41:20 UTC\r\nThe content in this post describes a method through which an attacker could persist administrative access to\r\nActive Directory after having Domain Admin level rights for about 5 minutes.\r\nComplete list of Sneaky Active Directory Persistence Tricks posts\r\nThis post explores how an attacker could leverage the built-in Active Directory management capability called\r\nGroup Policy and how to mitigate potential security issues.\r\nGroup Policy Overview\r\nOne of the key benefits to Active Directory is its management capability and core to this capability is Group\r\nPolicy. Group Policy has several parts to it and can be challenging to manage in a large enterprise without third-party tools.\r\nGroup Policy enables administrators to manage computers and users in Active Directory.  Group Policies are\r\nsaved as Group Policy Objects (GPOs) which are then associated with Active Directory objects such as sites,\r\ndomains, or organizational units (OUs). Group Policies can include security options, registry keys, software\r\ninstallation, and scripts for startup and shutdown and domain members refresh group policy settings every 90\r\nminutes by default (5 minutes for Domain Controllers). This means that Group Policy enforces configured settings\r\non the targeted computer.\r\nIn most Active Directory implementations, there is at least one GPO configured on the domain defining mandated\r\npassword, Kerberos, and domain-wide policies; at least one GPO configured for the Domain Controllers OU; and\r\nat least one GPO configured for a servers  and workstations OU. These GPOs define security settings specific to\r\nthe environment and often configure administrative groups, include startup/shutdown scripts, etc.. GPOs can be\r\nconfigured to set organization-defined security requirements at each level, and can be used for installing software\r\nand setting file and registry permissions. GPOs only apply to users and computers and can be filtered with groups\r\nor more specifically targeted using the Preferences component.  The “No Override” option ensures that the\r\nsettings in a Group Policy are applied even if a GPO closer to the resource has contradicting settings.\r\nThere are two Group Policy components:\r\n1. The “Group Policy Container” is stored in Active Directory (\u003cDOMAIN\u003e, System, Policies)\r\nhttps://adsecurity.org/?p=2716\r\nPage 1 of 14\n\n2. The files that actually contain the policy settings (collectively referred to as the “Group Policy Template“) are\r\nstored in SYSVOL.\r\nAll domain Group Policies are stored in the following domain share: \\\\\u003cDOMAIN\u003e\\SYSVOL\\\r\nhttps://adsecurity.org/?p=2716\r\nPage 2 of 14\n\n\u003cDOMAIN\u003e\\Policies\\\r\nEach Group Policy Object in Active Directory has the following attributes (on the policy object in AD):\r\ndisplayName: This is the name given to the GPO by the creator.\r\ngPCFileSysPath: This points to the location in SYSVOL where the associated GPO files (aka “Group\r\nPolicy Template”) are located.\r\ngPCMachineExtensionNames: This attribute lists the GPO client side extensions (CSEs) required to by the\r\nclient process the machine specific Group Policy settings.\r\ngPCUserExtensionNames: This attribute lists the GPO client side extensions (CSEs) required to by the\r\nclient process the user specific Group Policy settings.\r\nUsing the PowerShell Active Directory module cmdlet “Get-ADObject“, we can retrieve key GPO specific\r\nattributes for the GPO.\r\nThe PowerShell Active Directory module can be easily installed on Windows Server 2008 R2 (and newer) by\r\nrunning the following command in an Administrator PowerShell console:\r\nImport-module servermanager ; add-windowsfeature rsat-ad-PowerShell\r\nAdditionally, every Group Policy has a GPO GUID used to connect GPO components:\r\nThe GPO policy files are stored in a GPO object with the GPO GUID as the name.\r\nhttps://adsecurity.org/?p=2716\r\nPage 3 of 14\n\nThe Group Policy Template files in SYSVOL are stored in a folder with the GPO GUID as the name.\r\nThe GPO policy object Distinguished Name is added to the attribute “gPLink” on the Organizational Unit\r\n(OU) the GPO is linked to.\r\nWhen a new GPO is created, it can be created in AD and not linked (in which case, it does nothing), or linked to\r\nan OU, domain, or site. Upon creation, a new Group Policy Object is created in the Group Policy Container\r\n(\u003cDOMAIN\u003e, System, Policies) and the associated files are created in SYSVOL structure (based on GPO GUID\r\nname). When linking a Group Policy to an OU, for example, the OU’s “gPLink” attribute is updated with the\r\nGPO’s Distinguished Name. This provides a method for the computer to identify what group policies apply to\r\nitself as well as any that apply to logging on user(s).\r\nUsing the PowerShell Active Directory module cmdlet “Get-ADOrganizationalUnit“, we can retrieve the Group\r\nPolicies linked to the “Servers” OU.\r\nSYSVOL is the domain-wide share in Active Directory to which all authenticated users have read access.\r\nSYSVOL contains logon scripts, group policy data, and other domain-wide data which needs to be available\r\nanywhere there is a Domain Controller. The SYSVOL share is automatically synchronized and shared among all\r\nDomain Controllers.\r\nWithin this Policies folder are folders for each GPO with the folder name the same as that GPO’s GUID.\r\nEach GPO folder in SYSVOL has the following:\r\nMachine – this folder contains the machine specific settings for the GPO.\r\nUser – this folder contains the user specific settings for the GPO.\r\nGPT.INI – this file contains the configuration settings for the GPO.\r\nNote that the GPO is tracked in AD via the GPO GUID which has a separate AD object GUID for the AD object.\r\nThere are a few different reasons for this, and one of the key reasons is to ensure there are predictable GUIDs for\r\nhttps://adsecurity.org/?p=2716\r\nPage 4 of 14\n\nspecific Group Policy Objects regardless of the Active Directory instance. The “Default Domain Policy” GPO’s\r\nGUID is “31B2F340-016D-11D2-945F-00C04FB984F9” and the “Default Domain Controller Policy ” GPO’s\r\nGUID is “6AC1786C-016F-11D2-945F-00C04FB984F9” by default.\r\nIn this graphic the ObjectGUID attribute is “0115c3fa-1628-40d0-8a68-2d05530d6f76” which is obviously not the\r\nsame as the GPO GUID “31B2F340-016D-11D2-945F-00C04FB984F9”.\r\nGroup Policy Management\r\nGroup Policy management is often delegated in large enterprises so several different organizations are able to\r\ncreate, modify, and delete Group Policies. This issue with this is that Group Policy quickly gets unruly and\r\ndifficult to manage since many more than the originally designed (and selected) admins have GPO admin rights.\r\nThese rights are often delegated at the domain level, so edit (or full) rights apply to all domain GPOs, even those\r\nthat apply to the Domain (everything) and/or Domain Controllers.\r\nThe Group Policy Management Console (GPMC) is the primary tool for Group Policy administration and there’s a\r\nPowerShell module (GroupPolicy) which is extremely useful for reporting on and backing up GPOs (please\r\nbackup the domain GPOs regularly) using Backup-GPO.\r\nhttps://adsecurity.org/?p=2716\r\nPage 5 of 14\n\nGroup Policy Persistence Capability\r\nhttps://adsecurity.org/?p=2716\r\nPage 6 of 14\n\nGroup Policy was designed to provide simplified management of resources in a domain, though its capability can\r\nalso be co-opted by an attacker to push out malware, create/modify scheduled tasks, downgrade credential\r\nprotections, add a new local account to all computers that are added to the local Administrators group. and even\r\nchange existing security policies enabling clear-text password extraction.\r\nSome possibilities:\r\nConfigure a PowerShell or VBS script to set group membership at the domain or server level\r\nPerform one of the other “Sneaky Persistence Tricks” I outlined previously.\r\nRunning Invoke-Mimikatz on all Domain Controllers as SYSTEM every week.\r\nPull the KRBTGT account and then schedule a task that runs DCSync on certain computers throughout the\r\nforest using forged Kerberos tickets.\r\nInstall \u0026 Re-install malware on every computer in the Domain/Forest.\r\nDump all Microsoft LAPS passwords for all computer local Administrator accounts by running a\r\nPowerShell script automatically on one or all Domain Controllers. There are plenty of options for an\r\nattacker once Group Policy is part of their toolkit.\r\nIn fact, the Mandiant M-Trends 2016 report covering activity in 2015 includes information about how attackers\r\nare leveraging Group Policy to deploy malware:\r\nNote that the person who hacked Haking Team leveraged Group Policy as part of the hack:\r\nhttp://pastebin.com/raw/0SNSvyjJ\r\nRed Team Note on Group Policy:\r\nThe default Group Policy application behavior is to “refresh the group policy” on the client, though this doesn’t\r\nactually mean the GPO settings are re-applied. By default, the GPO’s settings are only reapplied if the GPO was\r\nmodified prior to the refresh. This means that one could reverse a GPO enforced setting via the computer’s\r\nregistry (typically with admin rights) and the unauthorized setting remains until the GPO is modified, after which\r\nthe GPO settings are re-applied.\r\nBlue Team Defenses:\r\nAfter testing, change the Group Policy default setting to re-apply GPO settings at every refresh (Process even if\r\nhttps://adsecurity.org/?p=2716\r\nPage 7 of 14\n\nthe Group Policy objects have not changed). This does have a potential performance hit on the client, but will\r\nensure all GPO enforced settings are re-applied.\r\nComputer Configuration, Policies, Administrative Templates, System, Group Policy, Configure security policy\r\nprocessing: Set to Enabled.\r\nAlso check the box for “Process even if the Group Policy objects have not changed”\r\nIt’s also recommended to configure the same settings for each of the following:\r\nComputer Configuration, Policies, Administrative Templates, System, Group Policy, Configure registry\r\npolicy processing\r\nComputer Configuration, Policies, Administrative Templates, System, Group Policy, Configure scripts\r\npolicy processing\r\nAs well as any other policy settings as needed.\r\nhttps://adsecurity.org/?p=2716\r\nPage 8 of 14\n\nGroup Policy Exploit Capability\r\nThough this post focuses on retaining domain-level privileged access (“Domain Admin” rights), there are several\r\nways in which an existing organization’s Group Policy configuration could be used to escalate access. The\r\nobvious method is to exploit existing Group Policy Preference credentials in the environment which enables an\r\nattacker to escalate access from domain user to server/application/OU admin, or even Domain Admin. The less\r\nobvious method involves finding GPOs linked at either the domain or a top level OU with custom security\r\nsettings.\r\nhttps://adsecurity.org/?p=2716\r\nPage 9 of 14\n\nBased on AD security assessments I have performed, I’ve found that organizations frequently have GPOs linked at\r\na high level with custom security settings providing edit rights to accounts that are not Active Directory\r\nAdministrators. This provides an avenue for privilege escalation since the GPO can be reconfigured to run a script\r\nor change security.\r\nPowerView, now integrated into PowerSploit, includes some interesting Group Policy enumeration capability via\r\nPowerShell.\r\nThe following example shows a Group Policy called “Full Auditing Policy” linked at the Domain level which has\r\n“Edit settings” rights delegated to the “Han Solo” (Server Admin) account.\r\nHan Solo is a member of the “Server Admins” group which is not a domain admin group.\r\nhttps://adsecurity.org/?p=2716\r\nPage 10 of 14\n\nSince Han Solo has the rights to edit this domain linked GPO, let’s modify it.\r\nAfter editing the Group Policy, this GPO will now add a scheduled task on every computer in the domain,\r\nenabling any type of activity the attacker wishes.\r\nhttps://adsecurity.org/?p=2716\r\nPage 11 of 14\n\n“Hidden Group Policy” – Group Policies Applied to Sites\r\nWe know that Group Policy is typically applied to Organizational Units and we can easily view them in GPMC.\r\nHowever, many admins don’t realize that while it is not best practice to link Group Policies to sites, there’s\r\nnothing preventing a Domain Admin (Enterprise Admin) from doing so.\r\nAll that’s needed is to select the AD sites that should be shown in the Group Policy Management Console and link\r\nthe new/updated Group Policies to the site(s)\r\nLooking at GPMC, we can see there are two Group Policies linked to the HQ Site and both of them were last\r\nmodified recently (hint, hint).\r\nhttps://adsecurity.org/?p=2716\r\nPage 12 of 14\n\nWould your current monitoring system notify on this change?\r\nMitigation\r\nAll Group Policies in the AD environment should be configured for a single purpose and monitored for\r\nunauthorized modification, especially GPOs linked to the domain, Domain Controllers OU, and/or a top level OU\r\nsuch as workstations, servers, admins, etc.\r\nDelegated permissions to Group Policy should be reviewed on a regular basis, especially those linked to top-level\r\nOUs. Only Active Directory administrators should have modify rights to GPOs applied to the domain, top-level\r\nOUs, and any GPOs linked to critical assets (Domain Controllers, servers, admin computers, etc).\r\nAdditionally, all sites should be reviewed for linked Group Policies since these GPOs can cross domain\r\nboundaries enabling privilege escalation across domains in the same AD forest.\r\nSYSVOL permissions are critical and must remain the same as the default settings since SYSYOL contains the\r\nactual Group Policy settings in files that are applied by GPO clients. If a GPO configuration file has permissions\r\nthat enables some on who is not an Active Directory admin to change the file, and thus change what action the\r\nGPO client actually performs, an attacker could quickly escalate permissions up to Domain Admin level.\r\nResources\r\nGroup Policy Basics – Part 1: Understanding the Structure of a Group Policy Object\r\nhttps://adsecurity.org/?p=2716\r\nPage 13 of 14\n\nLocal Group Enumeration using PowerView (includes Group Policy features)\r\nConfigure a Scheduled Task\r\nGroup Policy Preferences\r\nExploit existing Group Policy Preference credentials\r\nComplete list of Sneaky Active Directory Persistence Tricks posts\r\n(Visited 35,755 times, 1 visits today)\r\nSource: https://adsecurity.org/?p=2716\r\nhttps://adsecurity.org/?p=2716\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=2716"
	],
	"report_names": [
		"?p=2716"
	],
	"threat_actors": [],
	"ts_created_at": 1775434689,
	"ts_updated_at": 1775791244,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c481b5b19a37f62abfbcc0c315c479667acc1524.pdf",
		"text": "https://archive.orkl.eu/c481b5b19a37f62abfbcc0c315c479667acc1524.txt",
		"img": "https://archive.orkl.eu/c481b5b19a37f62abfbcc0c315c479667acc1524.jpg"
	}
}